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 extension registration? 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 extension.json and no longer any need for an extensions/MyExt/MyExt.php file, an extension that's installed via Composer must still be explicitly loaded with wfLoadExtension(), 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)

@Rudloff: 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 wfLoadExtension(). 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, Samwilson removed a notice that he did not like. In Special:Diff/3764155, Reedy 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 (Gerrit change 93008, Gerrit change 105092). When these changes were partially reverted (Gerrit change 132788), there was a great wailing and gnashing of teeth by the folks who put the un-discussed change into core (phab: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 Gerrit change 551346 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)

@BDavis (WMF) and Reedy: Thanks Bryan. I don't mean to start a squabble with this! :-) I just think the documentation should reflect reality. I'm totally grateful for all the work and thought you've put into this over the years and hope that nothing I say sounds like I'm critical of any of it. I think there are a few sort-of separate issues here:

• The patch Gerrit change 551346 you mention is about removing support of declaring MediaWiki version constraints in extensions' composer.json, and does not remove the possibility of installing extensions with Composer. (I think it's actually a good idea to do that, and that it's not the main question here.)
• The RFC in question dates from before it was possible to install an extension's files without enabling it. This is no longer the case. Indeed, one summary of the RFC was Daniel saying "the decision is to not use composer to register components. That is, composer's autoload feature should not be used to execute an extension's entry. Composer can and should be used to pull in any dependencies an extension may have, and it may also be used to install the code of an extension, and to auto-load an extension's classes. It shall not be used to activate the extension - for that, the wfLoadExtensions should be used."
• The status quo is that extensions are quite often installed with Composer. Even though we might not want them to be. If we really don't want to support Composer extensions, then we should remove the 'composer' parameter from {{Extension }}, and mark as abandoned all extensions under the mediawiki vendor namespace on Packagist.
• The winning case for composer.json in core is as you say always going to be for library management for core. It doesn't seem clear to me that this conflicts with extensions using it though; surely we'll still want to support extensions being able to install libraries too? Are you saying that there's a plan to remove the merge plugin? Or that extensions should have their own vendor directories?

Anyway, I'm happy to help clean things up on the wiki, but it feels like there's lots of conflicting discussion about how Composer is used, and not all of it is accurate. Also, the conflict feels to be along the lines of WMF vs 3rd party wikis, with "whatever is good for WMF deployment" winning. I know that our usage of Composer is often confusing for people new to MediaWiki, and I think there's something to be said for matching expectations from the broader PHP ecosystem.
But sorry, I didn't mean to go on; hope this doesn't sound like a rant! —Sam Wilson 06:45, 7 April 2020 (UTC)

I just think the documentation should reflect reality.

The warning literally does reflect reality. A feature exists, but is not supported by an RFC nor an active sponsor. You have a lot of reasonable points in your not-a-rant response, but none of them are directly pertinent to the removal of the warning.

I really do think its great that you and others care a lot about both Composer and the MediaWiki install experience. I don't love however the amount of effort that is put into clinging to the existing mediocre solution rather than working on a more useful and sustainable replacement. Nobody from this sub-set of the technical community helped build composer-merge-plugin, nobody from this sub-community has followed up with a better intermediate solution, and nobody from this sub-community has proposed a new RFC to address the technical or social advances that have happened since the failed attempt. For better or worse, MediaWiki is a do-ocracy. Make the better world you want or find someone to make it for you. --BDavis (WMF) (talk) 04:25, 8 April 2020 (UTC)