Request for Comment/Hybrid extension management: Difference between revisions
Jump to navigation
Jump to search
Vogel.robert (talk | contribs) (Created page with "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 ex...") |
(remove future) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
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 | 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 | 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 <tt>wfLoadExtension()</tt>. This second part was a special concern for multiple wikis hosted from the same codebase (i.e. wikifarms). | ||
==Proposal== | ==Proposal== | ||
The responsibility of "managing" extensions should be split up between Composer and MediaWiki's ExtensionRegistry. It would become a "hybrid system". | The responsibility of "managing" extensions should be split up between Composer and MediaWiki's ExtensionRegistry. It would become a "'''hybrid system'''". | ||
* Composer is responsible to download and update extensions | * Composer is responsible to download and update extensions and their libraries | ||
* ExtensionRegistry is responsible to check for inter-extension-dependencies as well as for version contraints (e.g. to the core MediaWiki version) | * ExtensionRegistry is responsible to check for inter-extension-dependencies as well as for version contraints (e.g. to the core MediaWiki version) | ||
This means that an incompatible version can be installed by Composer but ExtensionRegistry would not enable it. | |||
** extension.json | * <code>composer.json</code> => Evaluated at "installtime" | ||
* <code>extension.json</code> => Evaluated at "runtime" | |||
The current situation can easily be improved by some minor policy and software changes: | The current situation can easily be improved by some minor policy and software changes: | ||
# Extensions must not enable themselves automatically via installation by Composer (e.g. by <code>autoload.files</code>) | # Extensions must not enable themselves automatically via installation by Composer (e.g. by <code>autoload.files</code>) | ||
# Extensions must only declare dependencies to libraries in the <code>composer.json</code>. All dependencies to MediaWiki core versions and inter-extension-depenencies must be declared in the <code>extension.json</code> (By this, a [https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/551346/ virtual MediaWiki package] is not required). | # Extensions must only declare dependencies to libraries in the <code>composer.json</code>. All dependencies to MediaWiki core versions and inter-extension-depenencies must be declared in the <code>extension.json</code> (By this, a [https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/551346/ virtual MediaWiki package] is not required). | ||
# The WMF should not just allow, but encourage the use of " | # The WMF should not just allow, but encourage the use of "packagist-compatible" (must have fields like <code>name</code>, <code>type</code> and <code>extra.installer-name</code>) <code>composer.json</code> files in the extension repositories. This should be the case for all actively supported branches (LTS) of the WMF owned extensions. | ||
# MediaWiki's ExtensionRegistry must not break the wiki in case the requirements declared in <code>extension.json</code> (field <code>requires</code>) could not be met. Instead it should leave the extension disabled, log the issue and put out a proper message to the user/admin (e.g. in a section "Loaded but not enabled extensions" on "Special:Version") | # MediaWiki's ExtensionRegistry must not break the wiki in case the requirements declared in <code>extension.json</code> (field <code>requires</code>) could not be met. Instead it should leave the extension disabled, log the issue and put out a proper message to the user/admin (e.g. in a section "Loaded but not enabled extensions" on "Special:Version") | ||
==See also== | ==See also== | ||
* [https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer Orignial | * [https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer Orignial RFC from 2013] [https://phabricator.wikimedia.org/T467 T467] | ||
* [https://github.com/hallowelt/mediawiki/blob/REL1_31/_bluespice/build/bluespice-free-distribution/composer.json Example] of how BlueSpice MediaWiki distribution uses Composer to build releases | * [https://github.com/hallowelt/mediawiki/blob/REL1_31/_bluespice/build/bluespice-free-distribution/composer.json Example] of how BlueSpice MediaWiki distribution uses Composer to build releases | ||
* [https://packages.bluespice.com/ Example] of a MediaWiki extension package registry | * [https://packages.bluespice.com/ Example] of a MediaWiki extension package registry | ||
Latest revision as of 07:48, 3 April 2020
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).
Proposal
The responsibility of "managing" extensions should be split up between Composer and MediaWiki's ExtensionRegistry. It would become a "hybrid system".
- Composer is responsible to download and update extensions and their libraries
- ExtensionRegistry is responsible to check for inter-extension-dependencies as well as for version contraints (e.g. to the core MediaWiki version)
This means that an incompatible version can be installed by Composer but ExtensionRegistry would not enable it.
composer.json=> Evaluated at "installtime"extension.json=> Evaluated at "runtime"
The current situation can easily be improved by some minor policy and software changes:
- 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-depenencies must be declared in theextension.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,typeandextra.installer-name)composer.jsonfiles in the extension repositories. This should be the case for all actively supported branches (LTS) of the WMF owned extensions. - MediaWiki's ExtensionRegistry must not break the wiki in case the requirements declared in
extension.json(fieldrequires) could not be met. Instead it should leave the extension disabled, log the issue and put out a proper message to the user/admin (e.g. in a section "Loaded but not enabled extensions" on "Special:Version")
See also
- Orignial RFC from 2013 T467
- Example of how BlueSpice MediaWiki distribution uses Composer to build releases
- Example of a MediaWiki extension package registry