Upgrading to rc23 requires downgrading doctrine/collections

[cburschka-pwc]

In #3272 (rc17), the version requirement for doctrine/collections was relaxed in order to allow using doctrine/collections 1.4.0. Then in #3362 (rc23), this was reverted to force 1.3.x again.

Given that between rc17-rc22, Drupal Console has been working fine with 1.4, I'm somewhat confused that in rc23 it was apparently necessary to downgrade back, even though 1.4 should be fully backward-compatible.

Is there a specific bug that required this? The two packages seem to work fine when installed without composer, but I haven't tested it much.

$ composer require drupal/console ^1.0.0-rc23 drupal/console-core ^1.0.0-rc23 drupal/console-en ^1.0.0-rc23
./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
    - Installation request for drupal/console ^1.0.0-rc23 -> satisfiable by drupal/console[1.0.0-rc23].
    - Conclusion: remove doctrine/collections v1.4.0
    - Conclusion: don't install doctrine/collections v1.4.0
    - drupal/console 1.0.0-rc23 requires doctrine/collections 1.3.* -> satisfiable by doctrine/collections[1.3.x-dev, v1.3.0].
    - Can only install one of: doctrine/collections[1.3.x-dev, v1.4.0].
    - Can only install one of: doctrine/collections[v1.3.0, v1.4.0].
    - Installation request for doctrine/collections (locked at v1.4.0) -> satisfiable by doctrine/collections[v1.4.0].

[jmolivas]

@cburschka we detected doctrine/collections 1.4.0 requires php ^5.6 || ^7.0

1.4.0
https://github.com/doctrine/collections/blob/v1.4.0/composer.json#L16

1.3.0
https://github.com/doctrine/collections/blob/v1.3.0/composer.json#L16

Since latest stable release if Drupal 8 still requires >=5.5.9
https://github.com/drupal/drupal/blob/8.3.4/core/composer.json#L7

That is the reason we decided to switch back to 1.3.0

[cburschka-pwc]

Sorry if I'm not understanding composer dependencies right, but wouldn't it be better to lock it to 1.3.0 in composer.lock, while leaving the requirement itself as ^1.3 to leave maximum flexibility? As it is, DC would be incompatible with any other package that requires 1.4, regardless of your PHP version.

DC itself works fine with 5.6||7.0 after all, and therefore I don't think it should force all of its dependencies to be compatible with 5.5.9. Leaving the requirements open, and locking it at the older version, should allow composer to resolve it to the correct version for your system.

[hanoii]

I also think this is causing an odd behavior, if you run composer update --with-dependencies several times it seems that it's jumping back and forth between rc22 and rc23:

$ composer update --with-dependencies
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 5 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Updating drupal/console-dotenv (0.3.0 => 0.1.0): Loading from cache
  - Updating drupal/console-en (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
  - Updating drupal/console-core (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
  - Updating doctrine/collections (v1.3.0 => v1.4.0): Loading from cache
  - Updating drupal/console (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
Writing lock file
Generating autoload files
Creating packages services cache file:
./vendor/drupal/console/extend.console.uninstall.services.yml
> DrupalProject\composer\ScriptHandler::createRequiredFiles

$composer update --with-dependencies
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 5 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Updating drupal/console-dotenv (0.1.0 => 0.3.0): Loading from cache
  - Updating drupal/console-en (1.0.0-rc22 => 1.0.0-rc23): Loading from cache
  - Updating drupal/console-core (1.0.0-rc22 => 1.0.0-rc23): Loading from cache
  - Updating doctrine/collections (v1.4.0 => v1.3.0): Loading from cache
  - Updating drupal/console (1.0.0-rc22 => 1.0.0-rc23): Loading from cache
Writing lock file
Generating autoload files
Creating packages services cache file:
./vendor/drupal/console/extend.console.uninstall.services.yml
> DrupalProject\composer\ScriptHandler::createRequiredFiles

$ composer update --with-dependencies
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 5 updates, 0 removals
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Updating drupal/console-dotenv (0.3.0 => 0.1.0): Loading from cache
  - Updating drupal/console-en (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
  - Updating drupal/console-core (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
  - Updating doctrine/collections (v1.3.0 => v1.4.0): Loading from cache
  - Updating drupal/console (1.0.0-rc23 => 1.0.0-rc22): Loading from cache
Writing lock file
Generating autoload files
Creating packages services cache file:
./vendor/drupal/console/extend.console.uninstall.services.yml
> DrupalProject\composer\ScriptHandler::createRequiredFiles

[cburschka-pwc]

Indeed, it seems that composer is as likely to downgrade drupal/console as to downgrade doctrine/collections here - it's not really built for a scenario where a new version of A depends on an older version of B than it used to.

Until this is fixed, most installations will either get weird updating behavior, or be stuck at rc22 if they don't use --with-dependencies.

[hanoii]

The way I sorted this is by forcing console to go >= rc23:

        "drupal/console": "~1.0.0-rc23",

But this will affect a lot of users, specially those using https://github.com/drupal-composer/drupal-project

This at least sorts the odd issue. Also, without doing that, other composer updates were failing too.

[gapple]

Console should specify its minimum requirement (^1.30, since it needs to support PHP 5.5), and then it's up to composer on the local system to resolve the correct version.

If a project needs to ensure that dependencies are resolved against a particular version of PHP, then there is the platform config parameter to force composer to act as if the current system was a particular version of PHP. I develop locally with PHP 7, so I always set the platform property to 5.6 to match my current production environments.

When developing, if you need to make sure you're not breaking compatibility with PHP 5.5, you can use composer update --prefer-lowest, which should resolve to doctrine/collections 1.3 even on a system with PHP 5.6 where 1.4 would be supported. (Unless another package requires ^1.4.0, but that is the other package's problem for maintaining PHP 5.5 support)