Last modified: 2014-11-20 16:49:55 UTC
We should look at way to generate or update composer.json. We may want to look at a way to manage composer.json in update.php, etc.
Any changes that are made need to be usable by WMF and extension developers. Brian Davis, Ori and Jeroen have already spent time on this. After a discussion today, we hope to finally produce a use of compooser.php in MediaWiki that all will be able to use and appreciate.
Per Jeroen, we need to have the ability for end users (using the tarball or otherwise) to `composer require $package` without having to manually run through a horrible merge on update of mediawiki core. However, core requires composer because we're now starting to pull in external dependencies (like MonoLog / PSR3 logging). This requires that core have a composer.json file! We've resolved that the installer and the update scripts need to be aware of composer.json files and be able to merge new with old. We've also resolved that it is undesirable to ship a composer.json file with the tarball. Though; it was not agreed on if having it in git was acceptable. (See https://gerrit.wikimedia.org/r/#/c/132788/). It seems that the path forward is to write a hopefully simple stub around composer in the install and update scripts. This stub would merge the core dependencies file (I propose composer.core.json) into a non versioned composer.json. Then, the scripts would either run composer update or leave that up to the end user. We've resolved that so long as mediawiki does a best effort to merge the files that it is up to the end user to resolve any version dependency problems.
There's a way to achieve this with composer: https://getcomposer.org/doc/articles/custom-installers.md There's a very good example here: https://github.com/phpDocumentor/UnifiedAssetInstaller My rough sense of how this would work is this: MediaWiki's composer.json would specify a custom type and declare a dependency on the composer/installers package: { "name": "mediawiki/core", "type": "mediawiki-instance", "require": { "composer/installers": "~1.0" } } We'd implement a mediawiki-instance installer (like <https://github.com/composer/installers/blob/master/src/Composer/Installers/MediaWikiInstaller.php> is a mediawiki-plugin installer). The installer would merge additional requirements from an extensions.json file, if present. A skeleton extensions.json would be checked into git but then added to gitignore so that subsequent modifications don't dirty the repo state.
If custom installers are that flexible, sounds like it's flexible enough that it could merge in the library dependencies of extensions even if they weren't directly installed using composer.
I'm not really sure what you are trying to do with a extensions.json but please keep in mind that is not only extensions with type "mediawiki-extension" we are talking about. We also support type "mediawiki-skin" [0] that allows to install skin related extension via Composer. > The installer would merge additional requirements from an extensions.json file, if present. Just to be clear, an extensions.json is something MW does on its own right? An extension should only deploy a composer.json (because extensions.json is a not supported json and is only relevant to an internal MW process) as this is the official support declaration of dependencies via Composer. [0] https://packagist.org/packages/mediawiki/chameleon-skin
(In reply to Ori Livneh from comment #3) > A skeleton extensions.json would be checked into git but then added to > gitignore so that subsequent modifications don't dirty the repo state. We'd have to call it extensions-example.json, because once a file is added to the repository, gitignore will no longer affect it. (In reply to Ori Livneh from comment #3) > We'd implement a mediawiki-instance installer (like > <https://github.com/composer/installers/blob/master/src/Composer/Installers/ > MediaWikiInstaller.php> is a mediawiki-plugin installer). > > The installer would merge additional requirements from an extensions.json > file, if present. I think this is a pretty viable solution. My only concern is that now people would have to manually edit extensions.json in order to install new extensions. Which is why maybe we should take the Vagrant approach! It seems the Composer\Plugin\PluginInterface is meant to install plugins into Composer. Do we know if it would be possible to add custom commands to composer, similar to how we add "list-roles" with Vagrant?
(In reply to Tyler Romeo from comment #6) > Do we know if it would be possible to add custom commands to composer, > similar to how we add "list-roles" with Vagrant? It's in the works: https://github.com/composer/composer/issues/2761
(In reply to Ori Livneh from comment #7) > (In reply to Tyler Romeo from comment #6) > > Do we know if it would be possible to add custom commands to composer, > > similar to how we add "list-roles" with Vagrant? > > It's in the works: https://github.com/composer/composer/issues/2761 This issue now has a pull request proposed: https://github.com/composer/composer/pull/3377