Now that wikimedia/composer-merge-plugin is updated, the actions "install" and "update" works fine with Composer 2.0 -- tested on master after changing composer-plugin-api to ^1.1||^2.0 in composer.json.

In T266419#6871033, @Seb35 wrote:

Now that wikimedia/composer-merge-plugin is updated, the actions "install" and "update" works fine with Composer 2.0 -- tested on master after changing composer-plugin-api to ^1.1||^2.0 in composer.json.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/660984 will do that in master

Change 668339 had a related patch set uploaded (by Mainframe98; owner: Mainframe98):
[mediawiki/core@master] Support Composer 2.0 in ComposerInstalled

https://gerrit.wikimedia.org/r/668339

Change 668525 had a related patch set uploaded (by Reedy; owner: Mainframe98):
[mediawiki/core@REL1_35] Support Composer 2.0 in ComposerInstalled

https://gerrit.wikimedia.org/r/668525

Change 668339 merged by jenkins-bot:
[mediawiki/core@master] Support Composer 2.0 in ComposerInstalled

https://gerrit.wikimedia.org/r/668339

Change 668525 merged by jenkins-bot:
[mediawiki/core@REL1_35] Support Composer 2.0 in ComposerInstalled

https://gerrit.wikimedia.org/r/668525

On a fixed environment (HWM) that was recently updated to composer 2.0.6 (2020-11-07), I needed to perform this maneuver with 1.36.0-wmf.34 this morning.

cd mediawiki-1.36.0-wmf.34

## Fix composer
cp /opt/cpanel/composer/bin/composer .
./composer self-update --1
./composer update wikimedia/composer-merge-plugin --no-dev
composer update wikimedia/composer-merge-plugin --no-dev

'composer update --no-dev' with composer 2.0 did not work out-of-the box yet. Complained needed to run update with 1.x still.

Looks like a slight improvement is needed to Tim's patch in T248908: composer-merge-plugin support for composer 2.0/rMW7bdfc8356709: Allow Composer 2.0...

The exception only wants to be thrown if the old version of the plugin is loaded, as on a new install, the plugin might not be installed at all

Change 670629 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@master] ComposerHookHandler: Only throw exception if composer 2 is run, and 1.x of wikimedia/composer-merge-plugin is still installed

https://gerrit.wikimedia.org/r/670629

In T266419#6903125, @Celess22 wrote:

'composer update --no-dev' with composer 2.0 did not work out-of-the box yet. Complained needed to run update with 1.x still.

I presume by "out-of-the box" you mean a new install of MW where composer hasn't been run yet?

Yes:

git clone --depth 1 --single-branch --branch wmf/1.36.0-wmf.34 https://gerrit.wikimedia.org/r/mediawiki/core.git mediawiki-1.36.0-wmf.34

cd mediawiki-1.36.0-wmf.34
...

With 2.0:
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.

In T266419#6903217, @Celess22 wrote:

With 2.0:
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.

That's part of the PHPUnit dependancy tree. Or more specifically, it's a dependancy of phpunit/php-code-coverage (which phpunit/phpunit itself depends on).

It's irrelevant for this bug, and you probably don't want dev packages installed in production anyway.

It'll be fixed/sorted as part of the PHPUnit 9 upgrade; see T243600: Migrate MediaWiki core (and thus extensions and skins) to PHPUnit 9 for the most relevant task

Success!

For whatever its worth 1.36.0-wmf.34 was able to fire up, with adjustments, on cPanel version 94.0 build 2 (~2021-03-01). See https://docs.cpanel.net/changelogs/94-change-log/

Ctrl-F 'composer' on the page

Can see cPanel 93.9999.106 (2021-01-05) was the big one, with the change to composer 2.0.6.

Composer 2.0.6 is starting to pop up everywhere now en-masse as they all update.

I'll test any version you want for MW, just give me an update number to pull from.

In T266419#6903227, @Reedy wrote:

In T266419#6903217, @Celess22 wrote:

With 2.0:
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.

That's part of the PHPUnit dependancy tree. Or more specifically, it's a dependancy of phpunit/php-code-coverage (which phpunit/phpunit itself depends on).

It's irrelevant for this bug, and you probably don't want dev packages installed in production anyway.

It'll be fixed/sorted as part of the PHPUnit 9 upgrade; see T243600: Migrate MediaWiki core (and thus extensions and skins) to PHPUnit 9 for the most relevant task

Yep. Just letting you know.

That issue did not show up as far as I could see with composer 1, as I tested update with composer 1 and 2 separately. Maybe I missed it. I'm only doing --no-dev also.

If you want to test https://gerrit.wikimedia.org/r/670629 to confirm it fixes the issue you reported above, that'd be appreciated

  - Locking wmde/hamcrest-html-matchers (v0.1.1)
  - Locking zordius/lightncandy (v1.2.5)
Writing lock file
Installing dependencies from lock file
Package operations: 53 installs, 0 updates, 0 removals
  - Downloading wikimedia/composer-merge-plugin (v2.0.1)
  - Downloading cssjanus/cssjanus (v1.3.0)

Worked with no jujitsu.

Straight 'composer update --no-dev' right after clone with composer 2.0.6

I added your changes for that one file after the clone, which I did before I tried composer, which I did on a fresh clone of 1.36.0-wmf.34.

I'm sure this may not make any real difference for the WM environments.

But in a perfect world would be nice if could get pushed into 34 now for the masses, since many will be stuck when they get cPanel upgrades, like dominos falling.

It's not merged into master (or had any CR beyond my own self review. It needs a couple of tweaks IMHO), and there's no reason to cherry pick it into a WMF deployment branch as it doesn't fix anything for WMF deployment.

Why are you using the wmf deployment branches anyway?

Generally, we wouldn't advise using master (or the wmf branches) unless you really know what you're doing. That's what the stable and LTS releases are for.

Its a parallel POC for a project that's live on ~1.33. Code, servers, custom work all being validated as one would normally want and some expect. :) Not a lot of new unmanaged edits so its easy to revert, roll in or out of any version.

Thought you may want feedback, since the bulk of what you will get feedback on is only for WM.

Time flies. 1.36 will be released before you know it :)

Of course, 1.33 is EOL and has been since June 2020, so we wouldn't reccommend running that either ;).

And indeed, 1.36 will be released before we know. But merging the patch/fix into master will result in it being in 1.36 (it will also be backported to 1.35 so that can support composer 2.0 properly). So definitely, the feedback is useful, but there's definitely no use backporting it into the wmf deployment branch specifically. Again, when it's in master, it'll be in the next WMF branch; so if it gets merged before the next cut, it should be in 1.36.0-wmf.35.

Keep in mind also, that a huge number of people on 1.35 and below are about to have no choice for composer 2.0, and its was presumably easier for you if I come to you with direct feedback on the version you are on yourself. Which is part of the impetus for coming when I did and how I did to let you know.

I may go back and see how far back the juke works for possibly putting in the current docs:

cp /opt/cpanel/composer/bin/composer .
./composer self-update --1
./composer update --no-dev

Which may for some may work in perpetuity as a work around, for 1.35 et al.

I don't assume that below 1.36 that updating composer-merge-plugin will work.

In T266419#6903327, @Celess22 wrote:

I'm sure this may not make any real difference for the WM environments.

But in a perfect world would be nice if could get pushed into 34 now for the masses, since many will be stuck when they get cPanel upgrades, like dominos falling.

When I said "in a perfect world" was with an understanding that its not useful or practical to actually do. So I'm nto really worried about that.

In T266419#6903335, @Reedy wrote:

Of course, 1.33 is EOL and has been since June 2020, so we wouldn't reccommend running that either ;).

There are a huge number wikis on 1.33, including near-WF assets like Fandom. It's just a part of the ebb and flow as I'm sure you know.

In T266419#6903338, @Celess22 wrote:

In T266419#6903335, @Reedy wrote:

Of course, 1.33 is EOL and has been since June 2020, so we wouldn't reccommend running that either ;).

There are a huge number wikis on 1.33, including near-WF assets like Fandom. It's just a part of the ebb and flow as I'm sure you know.

Maybe so, but some people don't realise these things. So it's worth reminding people.

And Fandom have their own team of MW developers working on it; they are potentially more able to backport security fixes as necessary than some people who aren't programmers, aren't sysadmins etc and just want MW to work. It's not quite a fork these days, but it is still somewhat of one ;).

In the 1.35.2 point release, it will include version 2 of the composer-merge-plugin as part of the bundle. So if they're using the provided vendor repos, there is basically nothing for them to do.

The work on version 2 of the plugin was only finished in the last few weeks, so definitely couldn't have been included in the previous point releases. We're aware, the supporting work has mostly been done (docs TBC, but no point doing those until the release is out, otherwise we end up with more convaluted docs). And as 1.35 is an LTS, it made sense to backport things as they came available.

That and composer 2 was released after 1.35.0 anyway.

Rather than just copying it around, and then using composer self-update --1, you can just grab https://getcomposer.org/composer-1.phar to get the latest release of 1.x of composer too.

I also don't believe many users of MW (especially on cpanel type hosting) are likely to be following MW master anyway, never mind the wmf deployment branch.

I was just letting you know. Thanks for your attention in this.

Change 673123 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@REL1_35] ComposerHookHandler: Tweak handling of composer 2 and wikimedia/composer-merge-plugin

https://gerrit.wikimedia.org/r/673123

Change 673123 merged by jenkins-bot:
[mediawiki/core@REL1_35] ComposerHookHandler: Tweak handling of composer 2 and wikimedia/composer-merge-plugin

https://gerrit.wikimedia.org/r/673123

Change 670629 merged by jenkins-bot:
[mediawiki/core@master] ComposerHookHandler: Tweak handling of composer 2 and wikimedia/composer-merge-plugin

https://gerrit.wikimedia.org/r/670629