bd808 added a comment. In https://phabricator.wikimedia.org/T88436#1011709, @JanZerebecki wrote:
> This should probably be answered by @bd808 or @legoktm . > > In the long run not running composer in projects that use composer for > dependencies is probably a bad idea. As is duplicate declaration of > dependencies in two places without something that automatically synchronizes > them. Anyway that seems more like a long run thing, so unless we can switch > to use something nice for the next deployment (I don't follow the extension > registration and composer stuff in Mediawiki closely enough to know), we > should find a solution that works now: > > Wikidata CI works by running composer as one of the first things in each job, > deviating from that for one new Wikidata extension seems like a bad idea, > unless we are ready to change this for everything. The mediawiki/vendor repository is for Composer manged libraries that are needed to support MediaWiki and the extensions installed on the WMF production cluster. Wikidata was using Composer prior to the creation of this repository by creating their own bundle of Composer managed libraries inside the "built" mediawiki/extensions/Wikidata <https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FWikidata> repo. I'm not opposed at all to Wikidata moving to a model where they place their dependencies in mediawiki/vendor instead of an internal vendor collection. In the long term this will be good actually as it will make the WMF cluster more explicit about shared dependencies. Today if multiple extensions each ship their own version of class Foo the actual version of Foo loaded at runtime for a given request is dependent on the installation order of the duplicating extensions and how they expose Foo to the autoloader. TASK DETAIL https://phabricator.wikimedia.org/T88436 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: bd808 Cc: Legoktm, bd808, JanZerebecki, adrianheine, JeroenDeDauw, hashar, Aklapper, Wikidata-bugs _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
