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?

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

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):

In T208962#6078356, @Reedy wrote:

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?

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.

In T182472#6078375, @Reedy wrote:

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):

In T208962#6078356, @Reedy wrote:

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?

In T182472#6122026, @Legoktm wrote:

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

In T182472#6122025, @Legoktm wrote:

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

Change 591897 merged by jenkins-bot:

[mediawiki/core@master] registration: Add suggested dependencies to extension.json schema

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

Technically Resolved? Or do we want for this to have consequences, at least in the installer?

It’s be nice if we could at least have the installer mentioning it.

I don’t think any point in update.php etc