[09:19:09] <Kizule>	 Hi, I'm trying to fix searching via CirrusSearch on one wiki.
[09:19:13] <Kizule>	 After running this php extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php --reindexAndRemoveOk --indexIdentifier now --startOver
[09:19:38] <Kizule>	 I get this error: https://dpaste.org/bfyVU
[09:19:46] <Kizule>	 Any idea how to fix it? Wiki is using MediaWiki 1.39.
[10:39:04] <Vulpix>	 Kizule: You seem to be missing the search-extra ElasticSearch plugin https://phabricator.wikimedia.org/T215870#4991273
[11:06:35] <Kizule>	 Vulpix: Ah, I see. OpenSearch from Amazon doesn't have it, so I guess I'll just have to create another VM.
[18:43:30] <euouae>	 Hello when I run `php composer.phar update` on the composer.local.json file
[18:43:35] <euouae>	 what user should I run it under?
[18:50:47] <Vulpix>	 If you're on the server, since nobody else would have permission, you should run it as root. Buuuut! composer will warn you against running it as root!
[18:52:01] <Vulpix>	 I think the "correct" approach is to have a copy of the installation files somewhere on your profile or home directory, run composer under your user, then copy everything to the final location as root
[18:52:19] <euouae>	 yeah because I can't run it under www-data 
[18:52:30] <euouae>	 also, it seems that composer is missing. I don't understand why 
[18:52:38] <euouae>	 I've tried both `php composer.phar` and `composer ...` in the docker image
[18:53:31] <Vulpix>	 which docker image are you using?
[18:53:53] <euouae>	 <https://hub.docker.com/_/mediawiki>
[18:53:57] <euouae>	 mediawiki:latest is what I'm using
[18:54:57] <euouae>	 This is the compose.yaml I'm using: <https://termbin.com/8qqy>
[18:55:10] <euouae>	 I have no idea what's wrong. 
[18:56:01] <Reedy>	 I suspect the docker images don't run composer, and as such, don't include it
[18:56:14] <Reedy>	 They use the tarballs, which include vendor
[18:56:43] <gromit>	 We could add an extra image for that if that is useful
[18:56:59] <euouae>	 Wouldn't tarballs be harder to update?
[18:57:15] <euouae>	 I'd have to update in host and then move into docker container, right?
[18:57:35] <euouae>	 I'm inexperienced, so I don't have strong opinions on this. I don't know which way is better. 
[18:58:29] <euouae>	 Reedy: does it mean I should git clone my plugin into $IP/extensions/?
[18:58:38] <euouae>	 and ignore the composer.local.json?
[19:00:27] <euouae>	 Here's an example page that recommends to run `docker compose exec mediawiki composer update` <https://www.mediawiki.org/wiki/MediaWiki-Docker/Extension/Wikibase>
[19:00:40] <euouae>	 so I'm assuming there's something I'm doing wrong... and that composer is in fact available somehow
[19:00:59] <Vulpix>	 containers are meant to be static. You don't upgrade your container. You download a newer image which contains the updates
[19:02:12] <euouae>	 OK you're talking about pinned versions. Regardless, it would have to be downloaded in the host and not the container 
[19:02:22] <Reedy>	 That page you linked is using a different set of docker images
[19:02:31] <euouae>	 Oh really? MY BAD ... geezs.... 
[19:02:32] <Reedy>	 >Follow the Quickstart instructions at MediaWiki-Docker page.
[19:02:39] <Reedy>	 >Follow the directions in DEVELOPERS.md in the root of the mediawiki repository.
[19:03:01] <Reedy>	 which uses various WMF provided images (used in CI and such), which will contain composer (probably)
[19:03:18] <euouae>	 Those are dev images right? 
[19:04:05] <euouae>	 OK. Sigh, I'm a bit lost trying to configure MediaWiki with the official image. 
[19:06:22] <euouae>	 But I think it clears it up A LOT now that you've pointed out there's different MW images. I was very confused at the inconsistent instructions in different pages I've found online. 
[19:06:25] <euouae>	 Thank you 
[19:08:11] <Reedy>	 Many of us here get confused enough with the different docker images generally
[19:08:20] <Reedy>	 Calling them "official" is a bit grey too
[19:09:01] <Reedy>	 https://phabricator.wikimedia.org/project/profile/4585/
[19:09:04] <Reedy>	 https://phabricator.wikimedia.org/project/profile/3094/
[19:11:05] <euouae>	 I'm not even sure that that links hows 
[19:11:07] <euouae>	 shows * 
[19:28:14] <euouae>	 well then, which image do the instructions in <https://packagist.org/packages/mediawiki/ldap-provider> refer to?
[19:29:14] <euouae>	 is the packagist mediawiki vendor different to the hub.docker.com one?
[19:29:31] <Reedy>	 Don't think it refers to any image
[19:30:40] <Reedy>	 there's no MW vendor on packagist
[19:31:09] <Reedy>	 the one bundled in tarballs is what comes from https://github.com/wikimedia/mediawiki-vendor (under the specific release branch)
[19:32:07] <euouae>	 Reedy: "The package name consists of a vendor name and the project's name." <https://getcomposer.org/doc/01-basic-usage.md#package-names>. I was referring to the "mediawiki/" part 
[19:33:01] <Reedy>	 anyone can put anything in there
[19:33:37] <euouae>	 wouldn't you need to be the mediawiki user to put it there?
[19:33:47] <Reedy>	 no
[19:34:17] <euouae>	 um, what?
[19:34:36] <euouae>	 Does packagist really allow you to publish foo/bar without being user foo?
[19:35:13] <Reedy>	 ugh, the implementation is meh
[19:35:18] <Reedy>	 >Vendor names on packagist are protected once a package with that name has been published. That means you can not publish packages with a vendor name that already exists on packagist without permission. To be able to publish packages for an already existing vendor name you need to be maintainer of at least one package within that vendor. 
[19:35:26] <Reedy>	 Ok, so it's not quite as bad as I said, but it's not much better
[19:35:50] <euouae>	 ah right, so it's some group thing
[19:35:55] <euouae>	 hm... fair enough, still bad
[19:35:58] <Reedy>	 yeah
[19:36:14] <Reedy>	 a third party could be added to that package, and then has access to the namespace, apparently
[19:36:28] <Reedy>	 so it does almost become "anyone can put anything in there"
[19:36:33] <Reedy>	 "viral"
[19:36:56] <euouae>	 that's pretty bad 
[19:38:01] <Reedy>	 https://www.mediawiki.org/wiki/Composer/For_extensions
[19:38:29] <euouae>	 This recommends that I run composer which as I've noted is not available in the hub docker image
[19:38:52] <euouae>	 I think the instructions on the official image are telling me to copy directories into $IP/extensions
[19:38:53] <Reedy>	 It's more that... "installing extensions via composer is not officially supported, nor is it recommnded"
[19:39:31] <euouae>	 how do you deduce that? it's not a quote from that page
[19:39:59] <euouae>	 I went with the composer route because I thought that's what I had to do. I was misled by the different instructions online
[19:40:16] <Reedy>	 https://phabricator.wikimedia.org/T250406
[19:40:36] <Reedy>	 Similarly, https://phabricator.wikimedia.org/T249573
[19:42:04] <euouae>	 look, it's confusing because the docker image *includes* a composer.local.json-template
[19:43:04] <Reedy>	 Yeah, but what is in the contents of it?
[19:43:37] <Reedy>	 https://www.mediawiki.org/wiki/Composer
[19:43:40] <Reedy>	 > Composer is a dependency manager for PHP libraries. Starting with MediaWiki 1.25, MediaWiki core's external library dependencies are being managed with Composer. In addition, it can be used to manage the installation of MediaWiki extensions (available since MediaWiki 1.22). However this is currently not well supported. This may change in the future.
[19:44:19] <euouae>	 yeah... way to bury the lede
[19:44:29] <euouae>	 I actually missed that part despite reading that article
[19:44:52] <euouae>	 I read "MWs core deps managed with Composer ... can be used to manage inst of MW extensions ... " and though OK
[19:45:10] <Reedy>	 you won't find all extensions published on packagist
[19:47:27] <euouae>	 I was looking into LDAPProvider et all which I believe were on there 
[19:47:34] <euouae>	 anyway I was misled. I see I just have to include the directories