require symfony/console ~2.8|^3 -- but the package is fixed to v6.4.7

[hesco]

jenkins@efc9c26-01965:/opt/local/my_site_name$ composer require civicrm/cv

./composer.json has been updated Running composer update civicrm/cv Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages.

Problem 1

• civicrm/cv[v0.1.0, ..., v0.1.1] require symfony/console ~2.3 -> found symfony/console[v2.3.0, ..., v2.8.52] but the package is fixed to v6.4.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
• civicrm/cv[v0.1.2, ..., v0.2.1] require symfony/console ~2.8 -> found symfony/console[v2.8.0, ..., v2.8.52] but the package is fixed to v6.4.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
• civicrm/cv[v0.2.2, ..., v0.3.13] require symfony/console ~2.8|^3 -> found symfony/console[v2.8.0, ..., v2.8.52, v3.0.0, ..., v3.4.47] but the package is fixed to v6.4.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
• civicrm/cv[v0.3.14, ..., v0.3.48] require symfony/console ^4 -> found symfony/console[v4.0.0, ..., v4.4.49] but the package is fixed to v6.4.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
• Root composer.json requires civicrm/cv * -> satisfiable by civicrm/cv[v0.1.0, ..., v0.3.48].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions. You can also try re-running composer require with an explicit version constraint, e.g. "composer require civicrm/cv:*" to figure out if any version is installable, or "composer require civicrm/cv:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

jenkins@efc9c26-01965:/opt/local/my_site_name$ jq '.require' composer.json

{ "civicrm/civicrm-core": "^5.73", "civicrm/civicrm-drupal-8": "^5.73", "civicrm/civicrm-packages": "^5.73", "composer/installers": "^2.0", "drupal/core-composer-scaffold": "^10.2", "drupal/core-project-message": "^10.2", "drupal/core-recommended": "^10.2" }

[demeritcowboy]

Hi @hesco the docs now suggest either downloading the phar so it can be shared among sites (it won't conflict), or if you really want to use composer then run composer require civicrm/cli-tools - see second point at https://github.com/civicrm/cv#download, or https://docs.civicrm.org/installation/en/latest/drupal/#drupal10-download

[hesco]

@demeritcowboy ++

Thanks mate, that did the trick.

The upside of automating these processes is that . . .

I am saved the tedium of reviewing that documentation every time I install a new site.

The downside of automating these processes is that . . .

I face the tedium of digging through my own automation code to root out these issues which would be avoided if I had only reviewed the documentation and hand built it from scratch, accounting for these upgraded processes as they are introduced.

I have spent far too long restoring my ability to upgrade this site.

[demeritcowboy]

Haha yes it's the downside of fast-moving software - anything you do is obsolete in a few months.