Composer and NPM install failures

Software Support
1

Greetings,
Just following recipes in the documentation (I am not a sysadmin), and am running into trouble.

We are on a late-model Ubuntu server and I have ensured all packages are up to date.

Trying to run a composer installation today from GitHub - pkp/ojs: Open Journal Systems, so I guess we are on v3_3_1

Instructions:

composer --working-dir=lib/pkp install
composer --working-dir=plugins/paymethod/paypal install
composer --working-dir=plugins/generic/citationStyleLanguage install

First two commands run seamlessly
the third fails:

Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - seboettg/citeproc-php is locked to version v2.2.5 and an update of this package was not requested.
    - seboettg/citeproc-php v2.2.5 requires ext-intl * -> it is missing from your system. Install or enable PHP's intl extension.

But how to run composer update? It doesn’t look like the ojs package is ready for this:
Composer could not find a composer.json file in /var/www/ethicalfeast/www/ojs

So let’s give NPM a try.
npm install goes well enough (noting some warnings that look typical) but
npm run build fails with:

> OJS3@3.3.0 build
> vue-cli-service build --no-clean

sh: 1: vue-cli-service: not found

I tried to install, uninstall, and update vue per clues here: vue.js - npm run server throws error sh: 1: vue-cli-service: not found - Stack Overflow

But still getting the service not found error.

Any clues or additional info that I could check on?
Thanks!

2

Hi @JohnBrisbin

We maintain our hosted installations as git managed installations and use composer/npm. Our typical workflow is:

  1. Clone the git OJS repo
  2. Check out a stable branch that we want to track (usually stable-3_3_0 right now, using the main branch for production installations is not really recommended) with git checkout stable-3_3_0
  3. Go back into the top level OJS directory and run: git submodule update --init --recursive. This is the step that usually pulls in all of the ui-library stuff so maybe you missed it?
  4. Head into lib/pkp and run: composer --no-dev install
  5. Do the same thing in the citation plugin the paypal plugin. We actually go into these directories, we don’t run the commands from further up as you did.
  6. Then npm install/npm run build in the top level OJS directory.

That’s usually it.

Cheers,
Jason

3

Greetings Jason, thanks so much for the additional guidance.
Your workflow highlights a couple of things that are not obvious from the documentation, which is pretty sparse in places!
(1-2) From the beginning, I’m not actually sure the difference between cloning the repo and checking out a branch (in my context).
See the recipe offered here: (Installing OJS in a Namecheap hosting with Git | Knowledge Representation)
This is what I’m doing: simply cloning the repo, which gives me the ojs/ install directory, and I proceed with installation.
(3) Yep, I did this, no problem.
(4) Yep, no problem
(5) Good clue
go into the working-dir to run the composer commands. This was not obvious (to me).
the lib/pkp composer ran fine, but paymethod/paypal failed with what looks like should be an obvious fix, but I am stumped:
2021-07-08_07-04-49
(6) When I get there, great!
Thanks again for your help


4

Hi @JohnBrisbin

the main difference between cloning the repo and checking out a branch is that cloning the repo essentially just dumps everything in Github onto your harddrive, and then by default checks out the “main” branch. The main branch is the very tip of the spear development branch and from day to day may or may not work correctly as the dev team commit new code to it. Every once in a while, the dev team will create a new branch or a tag as needed and those branches and tags become the official versions of the software that get released. If you want to use git as a method to maintain your OJS installation you probably don’t want the main branch, you’ll want one of the stable branches like stable-3_3_0 or stable-3_2_1. That’s what the “git checkout stable-3_3_0” command does. It switches you to that branch. At that point running “git submodule update --init --recursive” then checks out all of the other bits like lib/pkp so that everything is synced up with the OJS branch you selected. Many of the plugins that come with OJS are in fact in their own repositories now and that command will pull them down as well.

I think I see what your issue is with respect to composer. If you’re actually going into the e.g. paypal directory, you no longer need the --working-dir command argument since what that’s now doing is telling composer to look for a directory called plugins/paymethod/paypal inside of the paypal directory (and it won’t find it). You can just run composer install instead.

Cheers
Jason

5

Jason, thanks so much for your assistance. Could I ask for a bit of clarification on the first steps though

You say that first you clone the git repo and then check out a specific branch.

Forgive me, but that sounds like setting up a clone of the ojs repo on my remote webserver, is that correct?

I would have thought I was just going to checkout a specific branch, always referencing the master repo which is on github, not my remote webserver.

So, I would expect a command (conceptually) like this:
git checkout https://github.com/pkp/ojs.git -v=stable-3_3_0

Just to clarify, I have no local development assets: this is all going straight onto my webserver. So what I’m trying to do is get your recommended stable-3_3_0 onto my remote.

What am I missing??

Thanks!

6

Hi John,

Yes, that is what you are doing here. The workflow for this is that if you run:

git clone https://github.com/pkp/ojs.git

You get a copy of the entire OJS repo on your web server. THEN if you run:

git checkout stable-3_3_0

You will see the following message:

Branch ‘stable-3_3_0’ set up to track remote branch ‘stable-3_3_0’ from ‘origin’ by rebasing.
Switched to a new branch ‘stable-3_3_0’

Which tells you that you’ve now got a stable-3_3_0 branch on your webserver that is tracking the official PKP OJS repo on github. If the dev team ever add commits to that official repo, you can pull them into your local copy on your webserver by running:

git fetch origin (origin, in this case, meaning https://github.com/pkp/ojs.git)
and then if you run:

git status

you’ll maybe see something like:

Your branch is behind ‘origin/stable-3_3_0’ by 10 commits, and can be fast-forwarded.

Essentially what this tells you is that there are now ten new commits to the official github repo, and because you originally cloned that repo, you can just run a command like git pull to pull those commits down into your repository.

The important thing to remember there is that running “git fetch” does not immediately put the origin commits into your own copy. It just stashes them off to the side. Only when you run “git pull” (or in some cases git rebase, if you’re doing your own dev work) do they actually go in.

If this all sounds like generally too much work I suppose it’s worth asking at this point why you want to build your OJS installation via git. Are you looking for a way to upgrade easily in the future?

Cheers,
Jason

1 Like
7

Thanks again Jason, you’re very patient and I appreciate the explanation.
You’re right of course, I ought to be just using the tarball install method which I shall do now.
There is something satisfying about getting composer to run properly, but I’ve exhausted my fascination with what can go wrong in the course of one installation, so I’m throwing the git experiment in the bin!
Kind regards,
JBrisbin

8

I’ve been using the programmatic method regularly, and the install process is much improved. git clone stable version | composer install | npm . . .

What was blocking our process was the non-standard missing php extension: “seboettg/citeproc-php v2.2.5 requires ext-intl”.

Citeproc should probably be using something better maintained than php extension “ext-intl,” but rolling it into our PHP install was the missing piece for now.

IUScholarWorks | Indiana University Libraries