Requests for comment/Extension management with Composer: Difference between revisions
m Reverted edits by 191.207.134.64 (talk) to last revision by Mglaser |
Worked in some of the comments |
||
| Line 26: | Line 26: | ||
=== Extension manager === |
=== Extension manager === |
||
A user interface is needed |
A user interface is needed. These are the main tasks that an interface should help the user with: |
||
* Install extensions and their dependencies |
* Install extensions and their dependencies |
||
* Check upgrade compatibility ("I want to upgrade to MW1.22, what's the status of my extensions for that?") |
* Check upgrade compatibility ("I want to upgrade to MW1.22, what's the status of my extensions for that?") |
||
| Line 32: | Line 32: | ||
=== Packagist === |
=== Packagist === |
||
All extensions using composer need to come from a central repository. We have to decide whether we want to maintain our own repo or use Packagist, the solution proposed by composer. We also need to establish how an extension gets from our git to the |
All extensions using composer need to come from a central repository. We have to decide whether we want to maintain our own repo or use Packagist, the solution proposed by composer. We also need to establish how an extension gets from our git to the package repository. Composer works with tags to indicate versions. This has already been standardized and adopted by many projects. In this case we can enforce extension versioning. If extension developers want to publish their work via the Extension Manager, they need to add tag following a certain convention. |
||
=== Development stack === |
=== Development stack === |
||
| Line 39: | Line 39: | ||
== Drawbacks / Issues == |
== Drawbacks / Issues == |
||
* No support for external tools like vipsscaler or lilypond. These need to be installed manually. |
* No support for external tools like vipsscaler or lilypond. These need to be installed manually. |
||
* Global scope assumtions need to be removed. More details can be found in [http://www.bn2vs.com/blog/2013/11/24/introduction-to-composer-for-mediawiki-developers/ this blog post] by Jeroen. |
|||
* No global scope: all global variables need to be declared first. Jeroen proposed to use $GLOBALS['wgNAME']. |
|||
* Composer is still in alpha. Jordi Boggiano, developer of Composer, wrote "The reason it is still in alpha though is that I don't like to call it beta while there is still a remote chance that something might need to be broken, and we still have a few open issues that relate to that". However, it's already very [https://packagist.org/statistics widely spread]. |
|||
* Composer is still in alpha. |
|||
== See also == |
== See also == |
||
Revision as of 09:45, 16 January 2014
| Extension management with Composer | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Markus Glaser |
| Document status | created, seeking feedback |
Rationale
Upgrading MediaWiki is fairly easy, finding matching extension versions is not. To make things worse, there are extensions that depend on other extensions. There is currently no standard way to deal with this. So we need to:
- Indicate an extension's version and dependencies
- Manage various dependencies among extensions
- Manage an extension's dependency on the MediaWiki version. This also helps to a faster deployment of extension updates
Current state of implementation
Proposal
This RfC aims at formalizing Composer support and discussing the neccessary steps to get there.
Standardize Composer support
With Semantic Mediawiki as a proof of concept, we need to identify and propagate widely used scenarios of extension installation.
Extension configuration
Some extensions need to be configured or they need to execute an installation routine. The most prominent example is to run update.php in order to add some extra tables. There's Composer support for scripts during the installation process: [3]. We need to establish best practices on how to handle these.
Extension manager
A user interface is needed. These are the main tasks that an interface should help the user with:
- Install extensions and their dependencies
- Check upgrade compatibility ("I want to upgrade to MW1.22, what's the status of my extensions for that?")
- Update extensions with a click if there is a newer version
Packagist
All extensions using composer need to come from a central repository. We have to decide whether we want to maintain our own repo or use Packagist, the solution proposed by composer. We also need to establish how an extension gets from our git to the package repository. Composer works with tags to indicate versions. This has already been standardized and adopted by many projects. In this case we can enforce extension versioning. If extension developers want to publish their work via the Extension Manager, they need to add tag following a certain convention.
Development stack
- Vagrant based installations can ship with Composer installed and use this as a basis for loading additional extensions.
Drawbacks / Issues
- No support for external tools like vipsscaler or lilypond. These need to be installed manually.
- Global scope assumtions need to be removed. More details can be found in this blog post by Jeroen.
- Composer is still in alpha. Jordi Boggiano, developer of Composer, wrote "The reason it is still in alpha though is that I don't like to call it beta while there is still a remote chance that something might need to be broken, and we still have a few open issues that relate to that". However, it's already very widely spread.