Request for Comment/Hybrid extension management - Revision history

Mark Hershberger: remove future

2020-04-03T12:48:37Z

remove future

← Older revision		Revision as of 08:48, 3 April 2020
Line 17:		Line 17:
	# 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.		# 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")

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

	==See also==		==See also==

Mark Hershberger at 12:46, 3 April 2020

2020-04-03T12:46:27Z

← Older revision		Revision as of 08:46, 3 April 2020
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 Composer as a way of installing and updating.		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 ~~concern~~ about using Composer as an extension-management-tool is that Composer "is for managing libraries, not extensions".		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==

Mark Hershberger: /* See also */

2020-04-03T12:17:19Z

Vogel.robert at 15:11, 2 April 2020

2020-04-02T15:11:31Z

← Older revision		Revision as of 11:11, 2 April 2020
Line 15:		Line 15:
	# 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 "~~pagagist~~-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.		# 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")

Vogel.robert at 15:09, 2 April 2020

2020-04-02T15:09:23Z

← Older revision		Revision as of 11:09, 2 April 2020
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 Composer as a way of installing and updating.		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 concern about using Composer as an extension-management-tool is ~~the~~ Composer "is for managing libraries, not extensions".		The main concern about using Composer as an extension-management-tool is that Composer "is for managing libraries, not extensions".

	==Proposal==		==Proposal==

Vogel.robert: Vogel.robert moved page RFC Composer 2 to Request for Comment/Hybrid extension management

2020-04-02T14:54:11Z

Vogel.robert moved page Request for Comment/Hybrid extension management to Request for Comment/Hybrid extension management

← Older revision

Revision as of 10:54, 2 April 2020

Vogel.robert at 14:52, 2 April 2020

2020-04-02T14:52:21Z

← Older revision		Revision as of 10:52, 2 April 2020
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 ~~Somposer~~ as a way of installing and updating.		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 concern about using Composer as an extension-management-tool is the Composer "is for managing libraries, not extensions".		The main concern about using Composer as an extension-management-tool is the Composer "is for managing libraries, not extensions".

	==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 an their libraries		* 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		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~~		* <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:

Vogel.robert: 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..."

2020-04-02T14:39:39Z

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..."

New page

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==
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:
# 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).
# The WMF should not just allow, but encourage the use of "pagagist-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")

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

==See also==
* [https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer Orignial RCF 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://packages.bluespice.com/ Example] of a MediaWiki extension package registry

← Older revision		Revision as of 08:17, 3 April 2020
Line 22:		Line 22:

	==See also==		==See also==
	* [https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer Orignial ~~RCF~~ from 2013] [https://phabricator.wikimedia.org/T467 T467]		* [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