Dependency on composer_manager makes it impossible to install when using composer_autoloader

Created on 20 April 2017, over 7 years ago
Updated 16 November 2023, about 1 year ago

I do not understand why the dependency on composer_manager has been needed.

For example, I'm using composer to manage some Drupal 7 installations, identical to how we use the alternative way provided by drupal-composer skeleton for 8.x (I maintain the d7 branch of it).

If I want to install drupal/s3fs:~3.0 using composer, it fails if I already have installed composer_autoloader, as it conflicts with composer_manager.

Composer_manager should be a suggestion and documented how to be used, and not a dependency in this case, as it's not a module that helps to gain a modern development workflow like we tried and implemented for D8, and for D7 as well.

Can you take out the "hard" dependency on composer manager from s3fs.info? Drupal official repos still use that to combine information in composer.json and creates the problem.

I attached a patch to make it quick :)

mbp2011:mygynecologist.ru.drupal madalin$ composer require drupal/s3fs:~3.0@dev
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: remove drupal/composer_autoloader 1.1.0
    - Conclusion: don't install drupal/composer_autoloader 1.1.0
    - drupal/s3fs 3.x-dev requires drupal/composer_manager * -> satisfiable by drupal/composer_manager[dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 1.8.0, 1.7.0, 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.0, 1.0.0-rc1, 1.0.0-beta7, 1.0.0-beta6, 1.0.0-beta5, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha1, dev-6.x-1.x, dev-6.x-2.x, dev-7.x-1.x, dev-7.x-2.x, dev-8.x-1.x].
    - drupal/s3fs 3.0.0-alpha0 requires drupal/composer_manager * -> satisfiable by drupal/composer_manager[dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 1.8.0, 1.7.0, 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.0, 1.0.0-rc1, 1.0.0-beta7, 1.0.0-beta6, 1.0.0-beta5, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha1, dev-6.x-1.x, dev-6.x-2.x, dev-7.x-1.x, dev-7.x-2.x, dev-8.x-1.x].
    - drupal/composer_manager dev-2.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 2.x-dev conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-1.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.x-dev conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.8.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.7.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.6.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.5.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.4.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.3.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.2.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.1.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-rc1 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta7 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta6 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta5 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta4 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta3 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta2 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-beta1 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager 1.0.0-alpha1 conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-6.x-1.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-6.x-2.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-7.x-1.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-7.x-2.x conflicts with drupal/composer_autoloader[1.1.0].
    - drupal/composer_manager dev-8.x-1.x conflicts with drupal/composer_autoloader[1.1.0].
    - Installation request for drupal/composer_autoloader ~1.1 -> satisfiable by drupal/composer_autoloader[1.1.0].
    - Installation request for drupal/s3fs ~3.0@dev -> satisfiable by drupal/s3fs[3.x-dev, 3.0.0-alpha0].


Installation failed, reverting ./composer.json to its original content.
🐛 Bug report
Status

Needs work

Version

3.0

Component

Code

Created by

🇬🇧United Kingdom imadalin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇨🇦Canada noah

    When I check the "No Composer Manager" checkbox, the site immediately becomes unavailable with the following watchdog error:

    Error: Class "Aws\S3\StreamWrapper" not found in include_once() (line 26 of /path/to/module/s3fs/S3fsStreamWrapper.inc).

    It seems like, for reasons that I can't figure out, that class is being invoked before /vendor/autoload.php has run. I can eliminate the error by adding this at the top of the file:

    if (!class_exists('Aws\Sdk')) include DRUPAL_ROOT . '/../vendor/autoload.php';
    

    I haven't added that to the current patch because it seems like there must be a better way to handle this—what might be causing that to be invoked before everything has been autoloaded?

  • 🇨🇦Canada noah

    In case anyone comes across this and runs into the same issues I had: I think I was getting a class not found error when using S3 from the vendor directory because "Use S3 for private:// files" was checked—that would explain why other people haven't run into the issue, and it seems plausible that Drupal 7 would bootstrap the file paths before /vendor/autoload.php runs. I worked around the issue by adding this just above the "use" statements at the top of S3fsStreamWrapper.inc:

     if (!class_exists('Aws\Sdk')) {
      require_once DRUPAL_ROOT . '/../vendor/autoload.php';
    } 

    I'm not sure this is a smart solution, and this code specifically expects the web root in /web (which isn't common for D7), but I put a patch in a Gist in case it's useful to anyone. Remove the opening "/.." if the web root is the install root.

    One additional little thing: I couldn't get the s3fs_sdk_autoloaded variable to stick on a fresh install because the settings aren't saved if the SDK isn't found (and the SDK can't be found until the settings are saved). The variable can be set using Drush, then everything else works:

    drush vset s3fs_sdk_autoloaded 1

  • Status changed to Closed: outdated 4 days ago
  • 🇺🇸United States cmlara

    Drupal 7 end-of-life triage:
    Drupal 7 will reach end of life on January 5th.

    The 7.x branches of S3FS do not have any additional planned releases.

    the 8.x-3.x and newer releases require composer managed installs and do not experience the issues described here.

Production build 0.71.5 2024