composer update for a single package may be silently stopped by a dependency conflict

[giorgiosironi]

My composer.json: https://github.com/giorgiosironi/drupal-core-composer-update (requires to be modified as explained in README after the first installation)

Output of composer diagnose:

Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.6.3
PHP version: 7.0.28-0ubuntu0.16.04.1
PHP binary path: /usr/bin/php7.0

Essentially, we are forced to run composer update $package $anotherRandomDependency because composer update $package does not pick up the new version due to some conflicts. Not sure if/how the behavior can be improved (or if there are other troubleshooting commands) for a more verbose diagnosis of the problem, but it required a few hours to find out which package $anotherRandomDependency was.

Commands to reproduce are listed in https://github.com/giorgiosironi/drupal-core-composer-update/blob/master/README.md

[xabbuh]

Is the other package a dependency that you are requiring yourself or is that installed as the dependency of another package? Does it make a difference if you run the command with the --with-dependencies option? Also, there is the why-not command which allows to troubleshoot why a particular package (or a version of that package cannot be installed).

[giorgiosironi]

Is the other package a dependency that you are requiring yourself or is that installed as the dependency of another package?

symfony/config is a dependency of another package in composer.json (drupal/console) but not of drupal/core, which is the package being updated. It is in the conflict field of a dependency of drupal/core.

Does it make a difference if you run the command with the --with-dependencies option?

Appears not to make a difference.

Also, there is the why-not command which allows to troubleshoot why a particular package (or a version of that package cannot be installed).

$ composer why-not drupal/core 8.5
drupal/core                                8.5.0       requires          symfony/class-loader (~3.4.0)                            
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/class-loader (but v3.2.14 is installed)          
drupal/core                                8.5.0       requires          symfony/console (~3.4.0)                                 
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/console (but v3.2.14 is installed)               
drupal/core                                8.5.0       requires          symfony/dependency-injection (~3.4.0)                    
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/dependency-injection (but v3.2.14 is installed)  
drupal/core                                8.5.0       requires          symfony/event-dispatcher (~3.4.0)                        
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/event-dispatcher (but v3.2.14 is installed)      
drupal/core                                8.5.0       requires          symfony/http-foundation (~3.4.0)                         
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/http-foundation (but v3.2.14 is installed)       
drupal/core                                8.5.0       requires          symfony/http-kernel (~3.4.0)                             
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/http-kernel (but v3.2.14 is installed)           
drupal/core                                8.5.0       requires          symfony/process (~3.4.0)                                 
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/process (but v3.2.14 is installed)               
drupal/core                                8.5.0       requires          symfony/routing (~3.4.0)                                 
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/routing (but v3.2.14 is installed)               
drupal/core                                8.5.0       requires          symfony/serializer (~3.4.0)                              
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/serializer (but v3.2.14 is installed)            
drupal/core                                8.5.0       requires          symfony/translation (~3.4.0)                             
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/translation (but v3.2.14 is installed)           
drupal/core                                8.5.0       requires          symfony/validator (~3.4.0)                               
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/validator (but v3.2.14 is installed)             
drupal/core                                8.5.0       requires          symfony/yaml (~3.4.5)                                    
giorgiosironi/drupal-core-composer-update  dev-master  does not require  symfony/yaml (but v3.2.14 is installed) 

This shows that a lot of locked symfony/* dependencies would need update. However I think --with-dependencies would solve that. I end up having to specify symfony/config here, which is not mentioned but has a conflict with symfony/dependency-injection:

$ composer update --dry-run drupal/core --with-dependencies
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
$ composer update --dry-run drupal/core symfony/config --with-dependencies
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 2 installs, 14 updates, 0 removals
  - Updating symfony/yaml (v3.2.14) to symfony/yaml (v3.4.7)
  - Updating symfony/translation (v3.2.14) to symfony/translation (v3.4.7)
  - Updating symfony/validator (v3.2.14) to symfony/validator (v3.4.7)
  - Updating symfony/serializer (v3.2.14) to symfony/serializer (v3.4.7)
  - Updating symfony/routing (v3.2.14) to symfony/routing (v3.4.7)
  - Installing symfony/polyfill-php70 (v1.7.0)
  - Updating symfony/http-foundation (v3.2.14) to symfony/http-foundation (v3.4.7)
  - Updating symfony/process (v3.2.14) to symfony/process (v3.4.7)
  - Updating symfony/event-dispatcher (v3.2.14) to symfony/event-dispatcher (v3.4.7)
  - Updating symfony/http-kernel (v3.2.14) to symfony/http-kernel (v3.4.7)
  - Installing psr/container (1.0.0)
  - Updating symfony/dependency-injection (v3.2.14) to symfony/dependency-injection (v3.4.7)
  - Updating symfony/console (v3.2.14) to symfony/console (v3.4.7)
  - Updating symfony/class-loader (v3.2.14) to symfony/class-loader (v3.4.7)
  - Updating drupal/core (8.4.6) to drupal/core (8.5.1)
  - Updating symfony/config (v3.2.14) to symfony/config (v3.4.7)

[stof]

the fact that composer why-not does not detect the conflicting package looks like a bug to me.

[Seldaek]

Composer 2 adds --with flag so you can run composer update --with drupal/core:8.5.1 for example which explicitly requires that version (without changing the requirement in composer.json), and does a partial update for it. I think that's the best way to solve this kind of use case, as it will run the full solver and it should tell you which locked package is causing issues.

Maybe we should actually change why-not to run this internally if it can't figure out an obvious reason why something is blocked.