Page MenuHomePhabricator

Let update.php check for composer updates in extensions
Open, HighPublic


update.php already checks for core composer dependencies being up to date, but does not check any of your extensions for similar out of date or newly added dependencies.

Today in the IRC channel I had to help a user who had updated his installation to 1.26 and ran into trouble over this, because his SyntaxHighlight extension was still using older pygments version. I think it should be easy enough to expand checkComposerLockUpToDate.php to advise users about which extensions might require a run of composer update as well.


Related Gerrit Patches:

Event Timeline

TheDJ created this task.Nov 26 2015, 1:56 PM
TheDJ raised the priority of this task from to Needs Triage.
TheDJ updated the task description. (Show Details)
TheDJ added a subscriber: TheDJ.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptNov 26 2015, 1:56 PM
Aklapper triaged this task as High priority.Nov 26 2015, 2:18 PM

Saw another posting about this problem. Tentatively setting higher priority if this becomes a common issue for confusion while we want a more seamless upgrade process.

ori set Security to None.
ori added subscribers: Legoktm, bd808.

Change 371965 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/core@master] update.php: Check for outdated composer deps of extensions

Change 371965 abandoned by TheDJ:
update.php: Check for outdated composer deps of extensions

Seb35 added a subscriber: Seb35.Sep 30 2018, 1:23 PM

I tested the patch with various extensions: without composer.json (LanguageTool), with composer.json containing a 'require' section, with composer.json without 'require' section. The first type is correctly detected, the second correctly says if the composer.lock inside the extension directory is obsolete, and the third type says there is no composer.lock file (it’s true but it’s normal in production).

I guess the patch was abandonned because the extension directory does not mandatorily contain a composer.lock file, the alternative scenario is the composer.json was registered in MW’s main composer.json in 'merge-plugin' section. At my knowledge these are the two scenarios to autoload Composer librairies in extensions. If correct the patch could be improved to check that composer.json 'require' section from extension directory match either composer.lock in extension directory either the global composer.lock.

Seb35 added a comment.Sep 30 2018, 2:00 PM

Also if this is implemented there could be "false" warnings because of T141225, because extensions could use version ranges (e.g. 2.3.*) in their Composer requirements.

It could be necessary to discuss this before implementing this change, because it will impact all extensions using Composer requirements with a policy not as strict as MediaWiki core’s one: either the users will start asking (legitimately) why they got warnings during updates either the extension mainteners would have to change their policy.

TheDJ added a comment.Sep 30 2018, 8:47 PM

I guess the patch was abandonned because the extension directory does not mandatorily contain a composer.lock file

It was abandoned because no one showed interest in it. I find it better to abandon such patches, rather than having them stay open for months and giving the vibe that someone (/me) will still be working on it.