Allow use of external YAML files for specifying extensions and skins

[yaronkoren]

Currently, the set of extensions and skins used in Canasta is defined in two files, extensions.yaml and skins.yaml - which, for every extension and skin, additionally set needed information like the URL from which to get the code, the exact revision to use, additional patches that need to be applied (fortunately none, for the next version!) and other steps that need to be taken post-download, like calling a Composer update.

I have been thinking for a while about treating these YAML files as separate from Canasta. The YAML files already seem to be a separate "beast" from the rest of Canasta. For this current upgrade of MediaWiki from 1.39 to 1.43, for example, the vast majority of changes are taking place within the YAML files, and not within the underlying code - and presumably that will be the case for most MediaWiki upgrades going forward, as the Canasta code matures and there is less need to modify anything outside of the MediaWiki software.

Tied in with that is there are currently many, perhaps dozens of, forks of Canasta, in most cases for use on specific sites - and my understanding is that, in most cases, the need for the fork is driven by the different set of extensions and skins being used. Presumably that will also be true of any future uses of the Canasta code to power other MediaWiki packages or wiki farms, like Open CSP.

Finally, there is the matter that the YAML files, once developed, can take on other uses outside of Canasta. The Canasta YAML files can already be found on the page Recommended revisions on mediawiki.org, and there is already one initiative (which I'm involved with) to use this set of recommended revisions for a non-Canasta use: an extension that would let admins install extensions and skins directly from the web interface.

What does it mean to separate these YAML files from Canasta? It means that Canasta would hold one or two environment variables, indicating the URL of the YAML file(s) to be used - and then these variable(s) could be set differently for each package, wiki farm or installation. In this way, any Canasta instance could hold a completely different set of extensions and skins, without the need to fork anything.

Anyway, I had been thinking it vaguely made sense to do something like this in the future, but thinking about it more now, I now feel that this is an ideal time to do it - as part of the release of the MediaWiki 1.43 version of Canasta, so that many or most of the forks of Canasta can simply go away with the transition to MW 1.43, replaced by just custom YAML files.

What changes would this require for Canasta? Probably not much, actually. I think this can be done with a few main changes:

• Merge extensions.yaml and skins.yaml into one file, maybe called contents.yaml in the main Canasta code (any instance with a custom YAML file could give their own file any name they wanted). This is not strictly necessary, but I think it would make the setup process easier for admins to just have one file - and in the future, it could allow for defining contents of the wiki besides just extensions and skins in that YAML file - like Linux utilities or PHP libraries that would only be needed for certain setups, or even setting which PHP version should be used.
• Rename the extensions-skins.php script to something more generic, like parse-contents-file.php, and modify it to just read one file. (Actually, on second thought, maybe there's no need to rename the script, for now.)
• Create an environment variable, or .ini file setting, or both, or something similar, to let any installation or installer script use a custom YAML file instead of the default one. (I'm not sure how this would best be done.)
• Get the Dockerfile to use this variable when passing a file in to the PHP script for parsing.

I admit that there's a certain irony in separating the specific set of extensions and skins used from the main Canasta code, since for some people (@tosfos was always a big proponent of this thinking), this set of extensions and skins was part of the heart of Canasta: Canasta is not a Docker image per se but a "best practices" approach to MediaWiki, with Docker as simply its current implementation. To the extent that anyone views the set of extensions and skins as integral to Canasta, I would say that having customizable contents really does appear to me to be a "best practice" - and if it allows for stopping all the endless forking, that's a strong indicator that this is the right approach.

I'm curious what people have to say about the general concept - and whether it really would prevent the need for forking Canasta. And for those who agree with the concept, it would be very good to hear how you think this customizable URL setting could best be implemented. @tosfos, @jeffw16, @freephile, @naresh-kumar-babu - any thoughts?

[yaronkoren]

Also cc @vedmaka, @pastakhov