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/]