Last modified: 2013-09-10 07:37:55 UTC
This is somewhat common for the Semantic extensions, and as things become more usable, it'd be nice if we could have something like the way ubuntu/debian have packages Depends - This extension cannot function without this other extenson Recommends - Having this extension enabled will allow extra functionality or similar Suggested - Having this extension enabled may allow extra functionality or similar Suggested might be OTT... Might be something to try and do when Chad does his extension setup rewrite...
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).