Page MenuHomePhabricator

1.27 tarball: Unnecessary library "ruflin/elastica 2.3.1" requirement
Closed, ResolvedPublic

Description

In the current tarball download of LTS version 1.27 [1] the composer.json lists library "ruflin/elastica" as a requirement. Therefore it is part of the vendor/ directory. I believe this is not needed, as the "ruflin/elastica" library is not required by MediaWiki core, but only by "Extension:CirrusSearch" (which again is not part of the tarball release). There might be other unnecessary requirements.

[1] https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.1.tar.gz

Event Timeline

Osnard created this task.Jan 30 2017, 3:21 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2017, 3:21 PM
Legoktm added subscribers: bd808, demon, Legoktm.

Currently the tarball bundles the mediawiki/vendor git repository, which is a collection of all the libraries that MediaWiki core requires plus anything required for usage on the Wikimedia cluster.

Originally the process of building the tarballs would run composer at release time to just pull in the minimum MW dependencies, however that was non ideal because there wasn't really a review process to see which code composer just pulled in, it required network access (making security releases more difficult), and it was non-deterministic.

So we switched to using mediawiki/vendor, which pulled in a few extra dependencies, but overall made the process safer.

Short of maintaining a separate repo for just the core dependencies (mostly seems like a hastle), I don't know of any other solutions. Note that we're also shipping the pear mail stuff in mediawiki/vendor to make it easier for people to configure their mail stuff even though it's not a core dependency as it's optional).

Please state what the exact version of the "current tarball download" is.

Osnard updated the task description. (Show Details)Jan 31 2017, 6:50 AM

@Aklapper 1.27.1; I've added the download link in the task description

@Legoktm Thanks for the explanation. I understand now why there is the mediawiki/vendor repo [1]. The problem with this approach is that in some cases (outdated versions of) core libraries take precedence over libraries that are shipping with extensions. E. g. I am using "ruflin/elastica" in version 5.x in my extension. Now when a user installs it on a tarball MediaWiki it will break, because the 2.3 version of MW core is being loaded.

I believe it would be better to have only actual dependencies in the tarball. Maintaining a seperate repo for core dependencies as you suggest sounds like a good idea.

[1] https://github.com/wikimedia/mediawiki-vendor

hashar added a subscriber: hashar.Jan 31 2017, 8:29 AM

I cant find a reference right now, but I thought mediawiki/vendor had REL branches populated via the composer merge plugin. Maybe we can look into it again?

@Legoktm Thanks for the explanation. I understand now why there is the mediawiki/vendor repo [1]. The problem with this approach is that in some cases (outdated versions of) core libraries take precedence over libraries that are shipping with extensions. E. g. I am using "ruflin/elastica" in version 5.x in my extension. Now when a user installs it on a tarball MediaWiki it will break, because the 2.3 version of MW core is being loaded.

In this case I don't think using the tarball is appropriate then. Since the user needs to run composer anyways to get the 5.x version of elastica, they should use composer to fetch all of MediaWiki core's dependencies too.

Osnard added a comment.Feb 2 2017, 9:30 AM

When a user downloads the extension with Special:ExtensionDistributor, shouldn't all composer defined dependencies be resolved in the resulting tarball?

Seb35 added a subscriber: Seb35.Dec 18 2017, 8:07 PM

This task is similar to T172927, given that ruflin/elastica is an example of the few librairies that are not necessary for all users.

demon closed this task as Resolved.Jan 12 2018, 10:38 PM
demon claimed this task.

This will be fixed for all future releases by removing mw/vendor from branches and fixing makerelease.py.