Page MenuHomePhabricator

Allow extension registration to suggest optional extension/skin or MediaWiki version
Open, Needs TriagePublic

Description

The extension registration has a requires field to enforce use of a specific version of MediaWiki core or an extension.

It should be possible to add a list of suggested extensions or MediaWiki versions to extension.json

For example the Scribunto extension has support for syntaxhighlighting with the Geshi extension, but there is no hint on install to install the optional extension.
Many extensions have VisualEditor support.

Due to feature flags or version detection the suggested extensions could be the same as required, but only with new versions. On install the available extensions could show a hint about the suggestion.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 8 2017, 11:16 PM
Agabi10 added a subscriber: Agabi10.Dec 9 2017, 1:02 AM
Reedy added a subscriber: Reedy.Feb 14 2018, 7:49 AM

I wonder if this is worth doing to the extent of adding it to extension.json schema, so it can be defined... Then making it useful inside MW later on?

Osnard added a subscriber: Osnard.Apr 22 2020, 11:24 AM

Just a remark: In BlueSpice we also have a lot of extensions that just integrate into, but do not depend on each other. I'd really love to be able to model this for the CI tools.

Change 591897 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@master] Add extension schema additions for optional things

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

Reedy added a comment.Apr 22 2020, 3:02 PM

So a question here is how exactly would we want to expose this?

Noting MW doesn't have an extension manager etc... So the only time in the UI that it would be appropriate (atm) is at install time... If there's an optional dependancy that isn't installed (or doesn't meet the version requirements) when using the web installer, should we be displaying an informational message?

Then from T208962: Allow specification of version limits for optional dependencies (which is kinda a more specific version of this task):

So would the idea be that if the optional thing exists, but the version doesn't match, it errors?

It's a slightly awkward semantic as optional doesn't mean it's required... It's possible they have an older version for other usages... Should it be erroring out in that situation?

This comment was removed by Esanders.

The complicated use case is where you have an "optional dependency" installed for other reasons, but can't upgrade to the required version.

e.g. I have VE 0.10 installed, but can't upgrade to 0.11 for whatever reason. I want to install another extension that has an optional dependency on VE 0.11, and I don't care that it won't be able to use VE.

This use case may be difficult for all extension developers to support and test for, as in many places we check for the existence of another extension by just probing the ResourceLoader registry, and not repeating the version check.

I would suggest then that we just throw an error as you suggested on the other task.

I would rather name it either "recommends" or "suggests", probably the latter.

So a question here is how exactly would we want to expose this?

I think for now allowing people to define the metadata is a good step that makes it worth adding to the schema.

Noting MW doesn't have an extension manager etc... So the only time in the UI that it would be appropriate (atm) is at install time... If there's an optional dependancy that isn't installed (or doesn't meet the version requirements) when using the web installer, should we be displaying an informational message?

Then from T208962: Allow specification of version limits for optional dependencies (which is kinda a more specific version of this task):

So would the idea be that if the optional thing exists, but the version doesn't match, it errors?

It's a slightly awkward semantic as optional doesn't mean it's required... It's possible they have an older version for other usages... Should it be erroring out in that situation?

isLoaded() supports version constraints, I think it's up to each extension to check for the proper version, and then gracefully degrade if it isn't met. Or do feature detection with method_exists, etc.

Also, is there any point in having a suggested MediaWiki core version? Or just on other skins/extensions?

Reedy added a comment.EditedMay 10 2020, 1:01 PM

Also, is there any point in having a suggested MediaWiki core version? Or just on other skins/extensions?

I think we have to bare in mind other extension developers don't follow the MW branch -> extension branch model. And then people use LTS MW, and much newer extensions...

And a good example of that is having 2 LTS versions active (which we'll have when 1.35 is released, until 1.31 is EOL'd in June 2021. That's nearly 10 months.

But more generally, for example, an extension might work on 1.31, but some newer features in a newer version, or the dependancy of newer PHP might mean it's more performant, or some features in newer MW core, mean the extension can do more.

It's probably an edge case, but the amount of extra effort to support it should be minimal

I would rather name it either "recommends" or "suggests", probably the latter.

It'd be nice to have some sort of standardisation (/following composer). Of course, we have dev-requires which doesn't ;)

We in RelEng want to allow repos to self-configure their CI more, and especially their dependencies: T185736: Feature request: Evaluate "require" field from "extension.json" in automated test environment

Using suggests (or whatever the group bikeshed picks) plus requires for all the repos to provide in for testing would probably allow us to do this.

Change 599048 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [WIP] ExtensionProcessor: Warn about unmet suggested dependencies

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