composer: Composer 2.7.0 usage with root user leads to plugins not being loaded

Perhaps what had confused me is that I didn’t change anything relevant from yesterday, but it just suddenly stopped working because of the implicit bump up in version from 2.6.6 to 2.7.0, but this was not visible anywhere, whilst the behavior changed.

Perhaps something like adding --strict to make sure that it always stops on warnings is useful.

Or perhaps make it default to stop on warnings, and adding an additional --ignore-warnings if you don’t care.

IMHO, this is a breaking change introduced in a minor version but semver states: MINOR version when you add functionality in a **backward compatible** manner.

Now all my containerized symfony applications are failing to deploy, and I don’t even use AWS ElasticBeanstalk.

Right, added it 👍🏻

It’s bitbucket pipelines running everything as root? Do you see a composer warning that plugins have been disabled because it’s running as root?

If so try setting the COMPOSER_ALLOW_SUPERUSER=1 environment variable, that’s a more appropriate fix than downgrading

As 2.7 breaks some AWS Elastic Beanstalk production environments, maybe add a quick note to the changelogs of composer. As I read the changelogs but still encountered the issue.

Something like:

If you see errors with missing commands (symfony-cmd: command not found) or other failures and you are relying on plugins and running Composer as root (for example when you use AWS ElasticBeanstalk), read https://github.com/composer/composer/issues/11839

For me it looks like this

and the error

sh: 1: symfony-cmd: not found

shows up after about 190 lines. So maybe I just didn’t make the connection that it was the root user thing on lines 2/3 that caused it.

Ah, brilliant, thank you @Seldaek !

                  script:
                      - apt-get update && apt-get install -y unzip
                      - docker-php-ext-install pdo_mysql
                      - cp .env.ci_test .env
                      - cp .env.ci_test .env.test
                      - export COMPOSER_ALLOW_SUPERUSER=1
                      - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
                      - composer install --prefer-dist --no-interaction
                      - ./vendor/bin/phpunit --testdox --colors="always"

This works without a problem and with composer v2.7.0.

This is closed but I’ll ask here because maybe somebody sees this. Today we also got lucky and took our productions site down. I’m wondering, shouldn’t Composer return error code so Docker would not finish the build? I mean if it’s not working properly under root, shouldn’t it be more vocal?

It seems like this change should have been update of major version.

I spent the entire morning debugging why at first, the web folder was not created by Drupal project scaffolding from my Docker image. I then used the COMPOSER_ALLOW_SUPERUSER=1 setting and that fixed that issue. I then spent the entire afternoon and evening trying to figure out why commands such as ./vendor/bin/drush from my container would fail with this error

Fatal error: Uncaught Error: Class “Drupal” not found in /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:93

After reverting COMPOSER_ALLOW_SUPERUSER=1 and applying the composer self-update 2.6.6 solution, things restarted working as intended. This indicates to me that there’s more to the solution than just setting COMPOSER_ALLOW_SUPERUSER

You’re right, I edited the title and issue to add a clear explanation of what is going on and how to work around it and when it is ok to work around. IMO in CI this isn’t a nasty workaround it’s fine, although I don’t really understand why these CI require you to run as root.

I am working on some tweaks to hopefully highlight the problem a bit closer to where it causes things to break.

I had the same problem in bitbucket-pipelines.yaml. It’s a simple setup, but I managed to fix it for now by adding a self-update

- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer self-update 2.6.6  # <-- without this, it fails
- composer install --prefer-dist --no-interaction

Online research shows, that this usually fails when symfony/flex is not installed, but I just updated it now to 2.4.4 and made sure it was installed.

Edit: Error is the same

Generating optimized autoload files

x packages you are using are looking for funding.

Use the `composer fund` command to find out more!

> symfony-cmd

sh: 1: symfony-cmd: not found

Script symfony-cmd handling the auto-scripts event returned with error code 127

Script @auto-scripts was called via post-install-cmd