olivier.beaton wrote:

As long as we don't get into the kind of trouble where the order of extensions start to matter, then we will get into deadlocks. I like that as long as you have all the extensions, somewhere, you're fine.

(In reply to comment #1)

As long as we don't get into the kind of trouble where the order of extensions
start to matter, then we will get into deadlocks. I like that as long as you
have all the extensions, somewhere, you're fine.

Indeed. After loading LocalSettings.php, then going through the extension list, and disable (or error?) where extensions don't have necessary dependencies.

Recommends/suggested extensions are obviously optional, so we don't need do anything

I suppose this needs to go via mediawiki-l to find out what we need

Like most things in $wgExtensionCredits, accepting an array/string, and the name of the dependancy MUST be the same as the 'name' of the other one

Depends makes sense per my "This extension cannot function without this other extenson"

Recommends/Suggested can be nicely merged as being extras

depends and optional would be fairly apparent

Listing dependencies is one thing, there will be work needed

Adding the information (when decided on naming) sooner rather than later should be fine, and be ignored, so can start going in whenever, for extensions that have them (SM* etc) can start building it.

Per Olivier, order shouldn't matter, as long as all extensions needed are loaded after LocalSettings (and then any other files you randomly include, like Initialise/Common Settings in WMFs case)

An iteration over all extensions would be needed to build the list of loaded extensions, and while we are at it, get the list of dependencies ("optional" we don't care about)

Filter the list of dependancies for dupes (or insert so we can't get dupes), then an array_diff ( array_diff( $needed, $loaded )) against loaded, and if count > 0

array(2) {

["Extension1"]=>
array(2) {
  [0]=>
  string(10) "Extension2"
  [1]=>
  string(10) "Extension3"
}
["Extension4"]=>
array(1) {
  [0]=>
  string(10) "Extension2"
}

}

We can then backwards look at all the extensions that aren't loaded, and pull out a list of names of which need extensions and come up with a simple list of dependancies, stopping code execution from going any furthere

I will most probably start using Composer for continuous integration (bug 42694). It is PHP dependency system, some of my finding are at https://www.mediawiki.org/wiki/Composer

This is now a bug and I am taking it. It is not going to be fixed any time soon though.

Resetting assignee, I am not actively working on this.

The discussion has popped up on wikitech-l again. Why not just use composer for all inter-extension dependencies? Are there technical limitations?

From bug 42694:

Antoine wrote:

I have setup a composer repository in labs:

http://integration-composer.instance-proxy.wmflabs.org/ (that URL will
eventually disappear).

Some basic doc:
https://www.mediawiki.org/wiki/Composer#Our_own_repository

So that was merely a sprint hack to get a proof of concept. Jeroen De Dauw has added composer.json files to the extension he is managing and even published a bunch of them on https://packagist.org/ .

For production, we can not rely on a third party so we need to setup our own composer repository, possibly with our own packagist installation which could well become the new extension distributor.

We will need to craft composer.json for all deployed extensions and craft a file for MediaWiki in production which will list the extension dependencies. Then adapt our deploy script to use composer to fetch the dependencies from our composer repository.

It is not necessarily but definitely need a couple week of focus to get it going and of course make sure we agree on using Composer has a dependency manager :-]

Note, the composer repository utility is https://github.com/composer/satis . That requires a bunch of dependencies such as twig (templating engine) and symfony/console (an awesome Symfony bundle to create console scripts).

This was partly resolved as part of T117277: Extend 'requires' section of extension.json to include extensions - it only implemented hard dependencies. Recommends and suggests would likely be good enhancements as well.

Where should the "suggests"/"recommend" message be printed to? If we would have something like "php maintenance/mwscript installExtension FooBar" which installs/updates an extension (like composer update/install), it would probably be easy to just print out, that dependencies are installed or that some dependencies are suggested by the extension. But currently, extensions are installed manually by adding it to the wfLoadExtensions function call.