Page MenuHomePhabricator

RFC: Remove ability to install extensions and skins with Composer
Open, Needs TriagePublic

Assigned To
None
Authored By
Reedy
Apr 7 2020, 12:03 AM
Tokens
"Dislike" token, awarded by freephile."Dislike" token, awarded by Akuckartz."Dislike" token, awarded by RHeigl."Dislike" token, awarded by JeroenDeDauw."Dislike" token, awarded by MarkAHershberger.

Description

  • Affected components: MediaWiki core's Composer helper for installing and updating extensions and skins.
  • Engineer(s) or team for initial implementation: TBD.
  • Code steward: TBD.

Motivation

In T467 it was decided not to officially support managing enablement of, or dependencies between, extensions via Composer. This is handled by ExtensionRegistry nowadays.

We should remove the half "support" still existing for those use cases from MediaWiki. Thus removing the expectation that people should be able to install MW or extensions via Composer, even though it's not offically supported.

Pages like https://www.mediawiki.org/wiki/Composer/For_extensions do not help the situation.

Proposal

  • Remove the pre-install-cmd and pre-update-cmd hooks from MediaWiki's composer.json, which are currently used to provide a composer-requirable "MediaWiki" version.
  • Deprecate and remove the then-unused MediaWikiVersionFetcher class.

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/551346/ was created to do this

See also T243297: Remove and cleanup composer/installers for removing composer/installers from extension/skin composer.json files
See also T250406: RFC: Hybrid extension management which is proposing to properly establish composer based extension management.

Event Timeline

Reedy created this task.Apr 7 2020, 12:03 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 7 2020, 12:03 AM
Reedy updated the task description. (Show Details)Apr 7 2020, 12:07 AM
Reedy updated the task description. (Show Details)Apr 7 2020, 12:12 AM

Change 551346 had a related patch set uploaded (by Jforrester; owner: MaxSem):
[mediawiki/core@master] Rm support for extensions requiring a MW version via Composer

https://gerrit.wikimedia.org/r/551346

daniel added a subscriber: daniel.Apr 15 2020, 8:51 PM

@Reedy can you flesh this out a bit more, so it follows the guideline at https://www.mediawiki.org/wiki/Requests_for_comment, and move it to the appropriate phase (probably phase 2).

MaxSem added a subscriber: MaxSem.Apr 16 2020, 12:15 PM

The situation with respect to use of composer in extensions has changed significantly since T467. I used to be opposed to composer use in extensions myself, but I have been convinced by seeing how composer is currently used in extensions. Today, the use of composer by some third parties to install extensions and maintain their infrastructure is quite impressive.

One of the early objections to composer use had to do with bypassing extension registration and using composer to enable extensions, but even Semantic MediaWiki has changed so that it no longer automatically enables itself. It is important to differentiate between installing an extension, which can supported in many ways, and enabling an extension.

There are many third party MediaWiki extension developers who are using composer in ways that greatly enhance their productivity and the quality of their code. There are things that composer should definitely NOT be used for (e.g. enabling extensions, expressing extension dependencies on other extensions, or in most cases autoloading code), and that current extensions should be updated in light of, but there are aspects of composer that are quite beneficial.

Since there has not been any similar functionality added to MediaWiki itself (nor should there be if an existing open source solution exists to provide that functionality), it seems reasonable that, rather than banning the use of composer, there be an accepted, well-documented approach to how extensions can use composer. Composer support should be optional, and it is fine if there is a limitation on extensions loaded in the Wikimedia infrastructure that prevents extension installation with composer.

Third party developers that I have spoken to are willing to make changes in their use of composer to comply with a reasonable policy when accepted, but would be dramatically against any attempt to remove all support for composer to install extensions.

daniel updated the task description. (Show Details)Apr 16 2020, 7:06 PM

I agree with everything @CCicalese_WMF has said above. Let's figure out a middle ground here; installing extensions with Composer is really useful!

Certainly, get rid of having an extension be able to require a version of MediaWiki; that's not too widely used and creates a slightly strange looping of dependencies.

But is this also proposing to remove the composer-merge plugin? In which case, how will extensions require other packages? Will each extension have their own vendor directory? What about clashing versions between extensions?

Reedy added a comment.Apr 16 2020, 9:55 PM

But is this also proposing to remove the composer-merge plugin? In which case, how will extensions require other packages? Will each extension have their own vendor directory? What about clashing versions between extensions?

This is definitely the supported part (requiring non MW skins/extensions 3rd party PHP libraries) of using composer in MediaWiki.

Even if we consider composer-merge-plugin a hack, I think there other tasks about finding better ways to handle this including/munging of sub dependancies into vendor

Oh right, that's good to know. Then it sounds like we'd have to remove the mergability of the require section of composer.local.json if we wanted to prevent people from installing extensions with Composer. Extensions would still have their own require section of course, but only include would work at the higher level.

[…] It is important to differentiate between installing an extension, which can supported in many ways, and enabling an extension.

[…] There are things that composer should definitely NOT be used for (e.g. enabling extensions, expressing extension dependencies on other extensions, or in most cases autoloading code), and that current extensions should be updated in light of, […]

I think it's fine for wikis to continue to use Composer to download the source code of extensions hosted on Packagist. MediaWiki is quite flexible around where the code comes from or where it lives on disk.

Would the removal of the current partial support affect that use? I assume it does, but it's not clear to me how. More detail on the specific problems that come up would help :)

Would the removal of the current partial support affect that use?

This is how the conversation floundered last time, I think! Because no, removing support for "specifying MediaWiki as a requirement of an extension" does not stop extensions from being installed with Composer. The patch above that MaxSem started is probably a good thing and should proceed, but not under the title of "remove ability to install extensions", because it doesn't do that. :)

Tgr added a subscriber: Tgr.EditedApr 19 2020, 4:23 PM

If this is to be an RfC, it needs proper rationale and cost-benefit analysis, not just a "hey let's break this functionality that an unknown fraction of MediaWiki users rely on". It's hard to even tell from the description what functionality is being broken.

Based on the patch, that functionality is MediaWiki exporting itself as a package (ie. pretending it was installed with something like composer install mediawiki/mediawiki 1.35.0, despite not actually being installable that way, for the purpose of allowing extensions to specify the supported version). So 1) all extensions specifying MediaWiki as a requirement in their composer.json that way would have to be updated (quick usage check: 3 in codesearch; I can find more on GitHub, but it's search syntax is not useful for getting a comprehensive result set), 2) after that, those extensions would still be installable via composer the same way they were before (so not sure if this would affect expectations at all), 3) the installation process would be more fragile (as composer wouldn't tell you you are installing an imcompatible extension; the extension registry has a similar check, but that's only invoked when running update.php, which is not a requirement for simple extensions, or when using the site, which is a bit too late). I don't see any obvious benefit there (unless the removed code was a maintenance burden).

That said, maybe a real composer package would be a better place for this code? People wishing to use MediaWiki via Composer could just composer install mediawiki/mediawiki (or mediawiki/mediawiki-composer-compat or whatever) which would not actually install MediaWiki but ensure Composer-based extensions work with it, while decoupling maintainer responsibilities for the Composer-specific logic and MediaWiki itself.

Krinkle updated the task description. (Show Details)May 3 2020, 11:14 PM
Krinkle moved this task from P1: Define to P3: Explore on the TechCom-RFC board.
Krinkle renamed this task from Remove ability to install extensions and skins with composer to RFC: Remove ability to install extensions and skins with Composer.May 5 2020, 11:15 PM
Krinkle updated the task description. (Show Details)
Akuckartz added a subscriber: Akuckartz.
freephile added a subscriber: freephile.