Talk:Composer/For extensions

"Nested" composer.json
Some extensions (well, only Wikidata and GoogleAPIClient basically) have multiple composer.json files, or keep theirs outside the "root" of the extension. The usage of such extensions is hopefully documented on their own pages, but perhaps developer documentation should be expèanded to cover this use case/how-to as well? nemobis@tools-login:/shared/mediawiki/extensions$ find -mindepth 3 -type f -name composer.json ./Wikidata/vendor/wikibase/data-model-serialization/composer.json ./Wikidata/vendor/wikibase/data-model/composer.json ./Wikidata/vendor/wikibase/serialization-javascript/composer.json ./Wikidata/vendor/wikibase/data-model-javascript/composer.json ./Wikidata/vendor/wikibase/easyrdf_lite/composer.json ./Wikidata/vendor/wikibase/javascript-api/composer.json ./Wikidata/vendor/wikibase/internal-serialization/composer.json ./Wikidata/vendor/composer/installers/composer.json ./Wikidata/vendor/serialization/serialization/composer.json ./Wikidata/vendor/data-values/geo/composer.json ./Wikidata/vendor/data-values/common/composer.json ./Wikidata/vendor/data-values/validators/composer.json ./Wikidata/vendor/data-values/number/composer.json ./Wikidata/vendor/data-values/time/composer.json ./Wikidata/vendor/data-values/data-types/composer.json ./Wikidata/vendor/data-values/javascript/composer.json ./Wikidata/vendor/data-values/serialization/composer.json ./Wikidata/vendor/data-values/interfaces/composer.json ./Wikidata/vendor/data-values/data-values/composer.json ./Wikidata/vendor/diff/diff/composer.json ./Wikidata/extensions/Wikidata.org/composer.json ./Wikidata/extensions/Wikibase/client/composer.json ./Wikidata/extensions/Wikibase/composer.json ./Wikidata/extensions/Wikibase/lib/composer.json ./Wikidata/extensions/Wikibase/repo/composer.json ./Wikidata/extensions/ValueView/composer.json ./Wikidata/extensions/PropertySuggester/composer.json ./Wikidata/extensions/WikimediaBadges/composer.json ./GoogleAPIClient/lib/composer.json ./DataValues/DataValues/composer.json ./DataValues/DataValuesInterfaces/composer.json ./DataValues/DataValuesCommon/composer.json ./WikidataEntitySuggester/php-client/composer.json
 * As far as I can tell both Wikidata and GoogleAPIClient bundle composer libraries/extensions inside of them, which is why they have composer.json files in sub-directories. Legoktm (talk) 03:04, 19 January 2015 (UTC)

Is using composer still recommended?
I thought that using composer to install extensions is a good idea. This wiki page suggest that it's the way to go, however I discovered now that there are some doubts. If composer is not the way to go, then that should be clearly marked here. Otherwise people invest time to support composer, although a different approach will be recommended soon. Ingomueller-net (talk) 14:43, 4 November 2015 (UTC)
 * Also a related issue: https://phabricator.wikimedia.org/T467

MediaWiki Packagist
Composer support for extensions seems to be deprecated but I really like using Composer to install my extensions so I created a Composer repository that allows you to install MediaWiki extensions with Composer even if they don't have a valid composer.json file. --Rudloff (talk) 10:58, 27 June 2016 (UTC)

Composer-installed extensions can be turned off
I realise that I might be flogging a dead horse here, but I'm a bit confused about why Composer installation of extensions has been deprecated. The reason given is:"the seemingly intractable problem of managing extensions for a Wikifarm when using Composer. A Composer managed extension can only be disabled by removing the extension entirely due to the manner in which these extensions ensure that their entry point file is loaded."

But is this really still the case with new-style ? It used to be true, because the entry point file of an extension would be autoloaded and therefore executed regardless of what was in LocalSettings.php — but now, with all autoloaded files listed in  and no longer any need for an   file, an extension that's installed via Composer must still be explicitly loaded with , mustn't it?

Am I missing something obvious? (I have a bunch of extensions installed with Composer, and it's so much easier for upgrading!)

—Sam Wilson 07:18, 16 December 2016 (UTC)

Still no Composer for extensions?
Is there any chance this RFC could be re-discussed? As several people have pointed out, now that extensions are loaded with wfLoadExtensions, the main reason for closing the RFC is gone.

Composer has become the defacto standard for installing PHP libraries and some other CMS like Drupal are fully embracing it for extensions as well.

I have been using Composer to manage extensions on several wikis (with MediaWiki Packagist) for a few years and it really makes installing them a lot easier (especially if you are using continuous integration).

--Rudloff (talk) 19:31, 6 November 2019 (UTC)


 * I agree, it looks like the original reason for not doing it no longer applies. There are certainly still some extensions that enable themselves directly when they're installed with Composer, but the ones that do this (such as Extension:Maps) are doing it intentionally. All other Composer-installable extensions still need . As far as I can see, the only technical barrier to more extensions being installed with Composer is a way to trigger an update to Packagist when a new release is tagged. Other than that, any extension can choose to set the relevant metadata in its composer.json and register on Packagist; then, it'll be installable. The release can be manually triggered on Packagist. So, yes, maybe a new RFC could be proposed. :-) Sam Wilson 22:07, 11 November 2019 (UTC)

Let's not wheel war on the warning about using Composer to manage extensions
In Special:Diff/3760871, removed a notice that he did not like. In Special:Diff/3764155, put it back and then followed up with wording changes in Special:Diff/3764155. Y'all, please leave the warning there.

I very much understand that a few extensions actually require installation via Composer. This however is a choice that the authors have made and then refused to unmake when the related technical RFC ended up being declined. The original feature was was introduced to MediaWiki with no public discussion, or at least none that was referenced in the commit messages. When these changes were partially reverted, there was a great wailing and gnashing of teeth by the folks who put the un-discussed change into core (T67188). I personally did a lot of work, both as a paid Wikimedia Foundation engineer and as an interested FOSS volunteer, to build composer-merge-plugin as a hack to try and get both sides most of what they wanted (use of Composer to manage PHP library dependencies for MediaWiki itself and installation of MediaWiki extensions via Composer for deployments). Having done all that work, I can say readily that it is all a pile of hacks that could cease to work at any time. And when it does cease to work, the winning use case is going to be library dependency management for core.

If you want a better install mechanism for MediaWiki extensions, you are a good person and you should work on a design and RFC for that. But please don't keep pretending that just because MaxSem gave up on merging when the same folks who committed the original feature objected that this means that abusing Composer to install extensions is a good idea. --BDavis (WMF) (talk) 00:37, 7 April 2020 (UTC)