It seems that a package manager is a reasonable way to manage a growing set
of dependencies.
Composer seems to me (without knowing too much about it) to be a reasonable
package manager.
I've heard the objection expressed that this will require new users of
wikibase/etc to "learn composer". Presumably the addition of a
composer.json file to the repo won't in itself prevent users from using the
released tarballs and ignoring composer altogether, so the only folks who
have to work with composer are those developing/admining a mediawiki
derivative with hairy dependencies, such that learning composer pays for
itself. Correct me if I misunderstand.
Can someone outline (for discussion's sake) the other objections to
composer? Otherwise, this discussion does not seem too knotty: someone
should submit a patch to "composer-ify" mediawiki/core and the various
extensions, the release process should include uploading versions to
https://packagist.org/ (optional, since composer can apparently install
directly from WMF git), and then people should use it for a while before
deciding if something else is needed (which may be just patches to
composer).
--scott, trying to drain the drama out of this discussion and understand
the technical issues.
ps. are patches needed to composer to make this process more
lightweight/require less modification to mediawiki/core? I note that
mediawiki seems to have support in
https://github.com/composer/installersalready.
pps. I think the multiple entry points as a technical issue with the
installer? By from my reading, there's no reason why you couldn't write a
separate 'mediawiki-composer' shell package that included just stub
index.php, api.php, etc files which loaded the appropriate entry point from
inside vendor/mediawiki or whatever. So (in my understanding) the changes
required to mediawiki/core are minimal. Please correct me if I'm wrong
(hopefully with a detailed list of the changes actually required).
--
(
http://cscott.net)