Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
hesco opened this issue May 28, 2024 · 3 comments
Open

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

hesco opened this issue May 28, 2024 · 3 comments

Comments

@hesco
Copy link

hesco commented May 28, 2024

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
Copy link
Contributor

demeritcowboy commented May 28, 2024

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
Copy link
Author

hesco commented May 28, 2024

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants