Replace composer.canasta.json with YAML additions

[yaronkoren]

The file composer.canasta.json contains a listing of the composer.json files of 19 extensions and one skin (as well as core MediaWiki's own composer.local.json file) that all require a "composer update" call on them, so that their dependencies can be downloaded and installed. It would be better if, instead of having this file, this information were added to the extensions.yaml and skins.yaml file. The script extensions-skins.php could then create, on the fly, a Composer JSON file resembling the current composer.canasta.json, and then the Dockerifle would call "composer update" on it, in the same way that it does already. (The extension-skins.php script could do the Composer call too, but given that this ties in to core MediaWiki too, that seems outside of its domain.)

I'm not sure what the new field name in the YAML files should be called. The following are all possiblities I thought of:

• composer: true
• use composer: true
• composer update: true
• composer required: true
• composer file: composer.json

The last of those, i.e. specifiying the file name for each one, only makes sense if an extension or skin could, practically speaking, ever use a Composer file name other than composer.json - if not, then it seems like a bad idea to require the name.

(The actual string used for "true" apparently doesn't really matter, because, if I understand the YAML specs correctly, any of "true", "yes", "y" and "on" will all be interpreted as "true". So this is just a question for the documentation.)

Moving this information to the YAML files will make it easier to make and track changes; and will also make the YAML files more usable outisde of Canasta, e.g. with the Recommended revisions project.

[yaronkoren]

@jeffw16 - any thoughts on this?

[yaronkoren]

By the way, instead of having a new Composer file, like the Dockerfile currently does, another option is to have extensions-skins.php go into each relevant directory and call "composer update" there. That definitely feels like less of a hack. Are there any advantages to combining all the Composer files into one batch - performance or anything else?

[yaronkoren]

Thinking about it more, maybe a better syntax would be:

• additional steps=composer update

That way, this syntax could support other required actions, besides just a Composer update. I'm thinking of three other steps that may need to be taken after installing an extension: calling MediaWiki's update.php, calling "git submodule update", and calling any setup scripts that the extension may have (at least two extensions, CirrusSearch and Semantic MediaWiki, have such scripts). The first, calling update.php, doesn't need to be specified for Canasta, since update.php is called at the end and handles everything at once - but it could certainly helpful if this YAML format becomes a more general format. The last one, with scripts, I'm not sure if it can be done in a non-hacky way - maybe there should be a separate field, like additional scripts, for that. But we could imagine some hypothetical very complex extension that has a full value for this one parameter, like:

additional steps=composer update, git submodule update, update.php, scripts ("maintenance/setupMain.php --reallyDoIt", "/maintenance/setup2.php")