Page MenuHomePhabricator

installer breaks when extensions depend on each other
Closed, ResolvedPublic

Description

For example, SemanticDrilldown will cause an installer failure if it is selected but SemanticMediawiki hasn't been loaded by the installer yet.

Dependency checks done by the extension, but I think they could be done by the installer better.


Version: 1.17.x
Severity: normal

Details

Related Objects

StatusSubtypeAssignedTask
OpenNone
InvalidNone
ResolvedCCicalese_WMF
ResolvedLegoktm
DeclinedNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedJdlrobson
ResolvedJdlrobson
InvalidNone
OpenNone
StalledNone
Resolveddemon
StalledNone
OpenNone
ResolvedUmherirrender
ResolvedUmherirrender
OpenNone
ResolvedLegoktm
StalledNone
OpenNone
Resolvedsbassett
Resolvedsbassett
OpenNone
ResolvedJdforrester-WMF
ResolvedPhysikerwelt
OpenNone
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedUrbanecm
DeclinedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
ResolvedDaimona
Resolvedmatej_suchanek
ResolvedDaimona
ResolvedDaimona
Resolvedmatej_suchanek
Resolvedmatej_suchanek
ResolvedPRODUCTION ERRORDaimona
ResolvedDaimona
OpenUmherirrender
ResolvedDaimona
ResolvedMarostegui
ResolvedBstorm
ResolvedDaimona
ResolvedUrbanecm
ResolvedMarostegui
Resolvedrook
OpenNone
OpenNone

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:29 PM
bzimport set Reference to bz29134.
bzimport added a subscriber: Unknown Object (MLST).

We'd have to standardise some way of noting depedancies

Chad, did we ever standardize on some extension metadata for the installer & configuration stuff? If not it's probably time for us to whip that out and see what we can do, at least for the name/author/url/depedency basics.

Be pretty spiffy to have that in for 1.18's installer; even if most config's still going to be separate a helper for enabling extensions is very useful, and I really want to push the idea of shipping some default extensions like ParserFunctions and WikiEditor.

$wgExtensionCredits['other'][] = array(
'path' => FILE,
'name' => 'Foo',
'author' => array( 'Foo Barson' ),
'url' => 'http://mediawiki.org/wiki/Extension:Foo',
'descriptionmsg' => 'foo-desc',
'dependencies' => array( 'bar', 'baz', 'lulz' ),
);

?

PHP code is probably not the best idea; to read it we'd need to execute the file, which starts modifying the program state.

We could play tricks with dividing the file up into parts and executing part of it, but honestly that just skeezes me out. :)

Metadata needs to be readable without executing any code, so we can pull it in for all available extensions with no security risk.

Waking up this thread as it may still be relveant. Since some time now "extension.json" file can be used to store such a information. There ia actually already a field reserved in the schema.

Change 424967 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] Handle extension dependencies in the installer

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

Change 424967 merged by jenkins-bot:
[mediawiki/core@master] Handle extension dependencies in the installer

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