- Affected components: Installation/Upgrading.
- Engineer(s) or team for initial implementation: MediaWiki-Stakeholders-Group, @Osnard .
- Code steward: TBD.
Over the last years there have been several attempts to use the Composer "package manager" as a way to manage MediaWiki extensions. At the moment there are already a lot of extensions that support Composer as a way of installing and updating.
The main concerns about using Composer as an extension-management-tool is that Composer "is for managing libraries, not extensions" and that extensions would bypass wfLoadExtension(). This second part was a special concern for multiple wikis hosted from the same codebase (i.e. wikifarms).
The responsibility of "managing" extensions should be split up between Composer and MediaWiki's ExtensionRegistry. It would become a "hybrid system".
- Composer can be used to download and update extensions and their libraries, but does not enable the extension
- ExtensionRegistry is responsible to check for inter-extension-dependencies as well as for version constraints (e.g. to the core MediaWiki version)
This means that an incompatible or unsatisfied extension may be downloaded by Composer but ExtensionRegistry would not install it.
- composer.json => Evaluated when downloading or updating source code.
- extension.json => Evaluated when running MW (installer/updater, and page views).
- Acceptance by the community: Composer is already widely used. Other open source communities also use it for "module-management", not just library-management
- Centralized vendor/ directory: Extensions can store their dependencies in a centralized directory, rather than having them in their respective sub-directory. Therefore multiple different versions of library code can be prevented. Also, Special:ExtensionDistributior seems not to handle libraries at all at the moment (T215713)
- Support for "SemVer" and "release branch compatibility model": Composer can use SemVer versions as well as release branches ("dev-REL1_*"). This makes it easy for a user to setup a reliable update mechanism (e.g. by "subscribing" to the "REL1_*" branches only).
The current situation can easily be improved by some minor policy and software changes:
Changes on the software
- ExtensionRegistry would throw an exception if requirements specified in extension.json were not met. Separate exception handling code (like SMW's SetupCheck) would be used for exceptions that happen during these early checks to ensure that administrators get better information than the WSOD.
Changes on the policy
- Extensions must not enable themselves automatically via installation by Composer (e.g. by autoload.files)
- Extensions must only declare dependencies to libraries in the composer.json. All dependencies to MediaWiki core versions and inter-extension-dependencies must be declared in the extension.json (By this, a virtual MediaWiki package is not required).
- The WMF should not just allow, but encourage the use of "packagist-compatible" (must have fields like name, type and extra.installer-name) composer.json files in the extension repositories. This should be the case for all actively supported branches (LTS) of the WMF owned extensions.
Potential action items
- Add composer-guidelines to the official MediaWiki extension developer resources
- Make all composer.json files in WMF extension/skin repos packagist-compatible
- Either register all WMF extension/skin repos with packagist.org or setup a dedicated package-registry (e.g. packages.mediawiki.org)
- Improve ExtensionRegistry dependency error handling (to be discussed)
- RFC from 2013 T467: RfC: Extension management with Composer
- Example of how BlueSpice MediaWiki distribution uses Composer to build releases
- Example of a MediaWiki extension package registry
- T249573: RFC: Remove ability to install extensions and skins with Composer
- T166956: Cannot use Composer's CLI to manage a project's dependencies
- T173141: Provide a way to install Composer dependencies after installing an extension, without updating all unrelated libraries