Re: [VuFind-Tech] Local composer dependencies

[Demian K. <dem...@vi...>]

Good points! A couple more things suggested by this:

1.) The problem with relying on composer.lock is that, in my experience, Composer doesn't always respect composer.lock files across versions, and it seems to change fairly rapidly. Having to constantly assist users getting a mysterious "you have a lock file from an old version of Composer" messages is not desirable. However, the idea of bundling a composer.phar file could counteract this potential problem, so that's definitely a good idea!

2.) The other challenge with removing the vendor folder is that developers relying on Git will have to remember to update the dependencies after pulling, just in case something has changed. This creates another source of human error which could waste time and cause confusion. Perhaps this can be offset with some kind of Git hook that automatically runs the composer update after a pull, but I don't have any experience with Git hooks, so I'm not sure how feasible this is, or whether it's possible to make it work properly cross-platform.

Like you, I have not yet concluded which way I prefer -- but honestly I think you've made both options sound more attractive, even though neither is clearly superior in all ways.

- Demian
________________________________
From: Markus Mächler [mar...@bi...]
Sent: Friday, July 24, 2015 3:26 AM
To: vuf...@li...
Subject: Re: [VuFind-Tech] Local composer dependencies

I have not yet concluded which way I would prefer but I can add some points to the discussion.

Make a second vendor folder
-I see your point on Composer’s job to load the most appropriate version of all components. However if there are compatibility issues it is also possible that Composer can not resolve them at all and throws an error. We can not completely avoid that.

- If we use the approach with a second, local composer.json we do not run into merge conflicts with the composer.json and the composer.lock file.

Remove vendor folder from repository
- If we would add our dependencies to the same composer.json as VuFind then the vendor folder definitely needed to be removed from the repository. Otherwise merge conflicts within the vendor folder might occur that can not be resolved.

- As long as the composer.lock is still in the repository we can be sure that the downloaded dependencies work with the current core implementation.

- For less-technical users we could include a composer.phar and provide a shell script that needs to be called that does the entire installation (or it could even be part of a click installer).

Looking forward to hearing some more thoughts on this.


On 22 Jul 2015, at 19:24, Demian Katz <dem...@vi...<mailto:dem...@vi...>> wrote:

Markus,

As you may already be aware, VuFind's use of Composer remains something that I'm a bit conflicted about. On the one hand, the current approach, with dependencies committed to the repository, makes VuFind deployment very simple -- users just check out the repo and go; no need to install or understand Composer. On the other hand, this is certainly not best/common practice -- most projects expect their users to retrieve their own dependencies.

I'm still debating whether VuFind should change to match the more common best practice or whether we should continue on the current course for the sake of our less-technical users.

That issue aside, the solution you propose is an interesting workaround for the current architecture. The problem is that I suspect that it will only work under certain circumstances. Part of Composer's job is to look at the whole dependency tree and load the most appropriate versions of all of the components. I could envision a scenario where a core VuFind dependency and a local dependency both depend on the same third-party component, but each run of composer resolves to a different version of the shared dependency, leading to possible unexpected/broken behavior. This may or may not be likely -- but it's at least possible.

Bottom line: I'm not sure whether it's better to implement this solution (which is a bit complicated and potentially error-prone) or to more strongly consider the possibility of changing VuFind's overall Composer strategy (also a little bit complicated and potentially error-prone, but at least in a more conventional way).

I'm definitely interested to hear your (and others') thoughts on this.

- Demian

-----Original Message-----
From: mar...@bi...<mailto:mar...@bi...> [mailto:mar...@bi...]
Sent: Wednesday, July 22, 2015 10:49 AM
To: vuf...@li...<mailto:vuf...@li...>
Subject: [VuFind-Tech] Local composer dependencies

Dear Demian

We recently had the demand for custom composer dependencies that are not in the composer.json file of VuFind core. Our first approach was to simply add it to the composer.json file in the project root directory.
It worked well but we ran into merge conflicts with the composer.json and composer.lock file after VuFind core changed its dependencies as well. We could solve these conflicts each time but we do not think that is the best approach.

To avoid future conflicts and to separate VuFind dependencies from our own dependencies we developed a second approach.
We added a second composer.json file to the folder "local". This gives the following folder structure:

local/composer.json
local/vendor/autoload.php
local/vendor/[custom vendor folders]

In order to make the autoloading work just a few lines need to be added to the index.php file.

If you are interested in including this feature to the core I would be very pleased to create a pull request.
If you or someone else of the vufind-tech list knows a better solution we would be pleased to hear it as well.

Kind regards
Markus



------------------------------------------------------------------------------
_______________________________________________
Vufind-tech mailing list
Vuf...@li...<mailto:Vuf...@li...>
https://lists.sourceforge.net/lists/listinfo/vufind-tech