Request for Comment/Hybrid extension management

From mwstake
Revision as of 10:39, 2 April 2020 by 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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 Somposer as a way of installing and updating.

The main concern about using Composer as an extension-management-tool is the Composer "is for managing libraries, not extensions".

Proposal[edit]

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 an 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

    • extension.json is runtime, composer.json is install time

The current situation can easily be improved by some minor policy and software changes:

  1. Extensions must not enable themselves automatically via installation by Composer (e.g. by autoload.files)
  2. 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 the extension.json (By this, a virtual MediaWiki package is not required).
  3. The WMF should not just allow, but encourage the use of "pagagist-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.
  4. MediaWiki's ExtensionRegistry must not break the wiki in case the requirements declared in extension.json (field requires) 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")

Future[edit]

Additionally to that the WMF could create it's own package repository (e.g. packages.mediawiki.org), where extensions would be listed. In addition to the extension description pages on mediawiki.org this could be the base for an extension store.

See also[edit]