On 2013-12-08 3:06 PM, Jeroen De Dauw wrote:
The side effect is that it removed the ability to use Composer to manage external components used by MW the library which is Tyler's proposed use case [0].
If the core community actually gets to a point where potential usage of third party libraries via Composer is actually taken seriously, this will indeed need to be tackled. I do not think we are quite there yet.
mediawiki-l has had a topic on UserMailer, we already have an RFC on starting to use 3rd party components inside MediaWiki[1], and I already had a commit (the RDFa code) happily using a composer installed library which is naturally broken now that composer.json is gone. This is *precisely* the time handling library dependencies using composer is relevant and why breaking the ability to manage libraries with composer is a problem. Frankly I find it absurd to suggest that the idea of installing libraries with composer needs to prove the community takes it seriously but the idea of installing extensions with composer doesn't need to prove it before jumping in and becoming a roadblock in being able to manage libraries with composer.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components
For instance, if we go down this road, getting a clone of MW will no longer be sufficient to have your wiki run, as some libraries will first need to be obtained. This forces change to very basic workflow. People who dislike Composer will thus scream murder. Hence I tend to regard this as a moot point for now. Though lets pretend this has already bee taken care off and look at solutions to the technical problem.
You're supposing the existence of a notable group I haven't seen before as if it were a big part of the community. In all our prior discussions on composer I don't recall seeing anyone coming out saying they hated the idea of using composer for libraries. The only people opposing composer those time I recall were people like me who only hated the idea of using composer for extensions, finding the idea absolutely absurd and a complete misuse of composer.
In any case this suggestion that we have people that hate composer enough we can't use it as part of our primary workflow is a complete red herring. Package managers like npm, bower, and composer that install packages locally can have their dependencies directly committed into source control. ie: Composer can still be used to manage dependencies and upgrade libraries but because the dependencies are committed no-one is required to run `{composer} install` after clone. Composer likes to dissuade you from this more than other package managers, but it is perfectly possible and reasonable to do if such a group was an issue. So even if we did have a group like that, it's completely irrelevant, a distracting red herring, not something that makes the real issue a moot point.
And we don't even need a big switchover to composer before blocking the ability to manage dependencies with composer.json becomes an issue. Using Composer for optional dependencies like PHPUnit and libraries that are only needed for specific features or only needed to do a full test run are the perfect way to dip MediaWiki's toes into composer and start getting things ready for composer to be used for more important things. I had *already* started doing this. PHPUnit was fully supported by composer. I had a commit for an RFC people liked using a composer installed 3rd party library for an optional set of tests. If that had gone through before composer.json was deleted we would already be having the discussion on how to handle composer dependencies in jenkins.
One approach, that is a lot more feasible then making MediaWiki (partially) library like, is to specify the MW dependencies somewhere else. Not in composer.json. Then when you install MediaWiki, these dependencies get added automatically to composer.json. And when you update it, new ones also get added. In a way, this is similar to the generation of LocalSettings. This is the approach I'd be investigating further if we actual where at a point where a technical solution is needed.
I'd like to note that this precludes the ability to add composer installed dependencies directly to git.
But more importantly, frankly the fact that we're talking about ways to avoid having a composer.json file committed to git like the standard for every other repo using composer is one of either: A) Another assertion that trying to install extensions via composer is a complete abuse and misuse of composer. B) A flaw in composer itself, which you may want to consider having fixed before you go installing extensions with it. Because composer is the *only* package manager I have seen that requires that all installed packages must be specified in the whatever.json file. Even npm and bower which work just like composer, installing libraries in a local folder, do not require that you add everything to package.json or bower.json.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]