You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current release of the package is 2.1.0 (corresponding to pressbooks/pb-cli@cc81de0). However, installing via the package command always installs the last release listed in the WP-CLI Package Index, which was 2.0.1 (corresponding to pressbooks/pb-cli@9fb35e6). If I try to specify the 2.1.0 version, I get the following error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires pressbooks/pb-cli 2.1.0, it is satisfiable by pressbooks/pb-cli[2.1.0] from composer repo (https://repo.packagist.org) but pressbooks/pb-cli[dev-master, dev-dev, 1.0.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.7.0, 1.8.0, 1.8.1, 1.8.2, 2.0.0, 2.0.1] from composer repo (https://wp-cli.org/package-index) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.
Describe how other contributors can replicate this bug
Run: wp package install pressbooks/pb-cli
Inspect lock file in ~/.wp-cli/packages/composer.lock
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires pressbooks/pb-cli 2.1.0, it is satisfiable by pressbooks/pb-cli[2.1.0] from composer repo (https://repo.packagist.org) but pressbooks/pb-cli[dev-master, dev-dev, 1.0.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.7.0, 1.8.0, 1.8.1, 1.8.2, 2.0.0, 2.0.1] from composer repo (https://wp-cli.org/package-index) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.
Describe what you would expect as the correct outcome
As the package index is no longer being updated, I'd expect Packagist to be the higher priority repository.
Let us know what environment you are running this on
OS: Darwin 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
Shell: /bin/zsh
PHP binary: /usr/local/Cellar/php@7.4/7.4.20/bin/php
PHP version: 7.4.20
php.ini used: /usr/local/etc/php/7.4/php.ini
MySQL binary: /usr/local/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.5.9-MariaDB, for osx10.16 (x86_64) using readline 5.1
SQL modes: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /Users/ned/Sites/cli-test
WP-CLI packages dir: /Users/ned/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.5.0
Provide a possible solution
There could be a flag to explicitly bypass the WP-CLI Package Index.
Provide additional context
This also happens in GitHub Actions.
The text was updated successfully, but these errors were encountered:
@selul I've been looking into this too and it looks like using canonical: falseshould fix the problem, but it doesn't.
After editing ~/.wp-cli/packages/composer.json to mark the wp-cli composer repository as canonical: false, if I run wp package list, the resulting output correctly reports that an update is now available where it wasn't before.
However, running wp package update still results in no change to the installed packages, and there does not seem to be a way to force this. Even removing the package and reinstalling it still installs the stale version of the package, even using Composer directly.
I found that adding packagist to the list of repositories before wp-cli fixed the problem for me (as my packages are all listed on Packagist (as is pressbooks/pb-cli).
If we had wp-cli as a non-canonical Composer repository, I would expect this to have the same behavior (a newer version of the package existing in another repository), but it seems that this specifically may be an upstream bug.
It's probably a good idea to update the definition of the wp-cli repository to use canonical: false anyways since it's almost guaranteed to be out-of-date, so this would be the more accurate definition of the repository IMO. Assuming there is an upstream bug, the above packagist repo order workaround should no longer be necessary.
Bug Report
Describe the current, buggy behavior
I'm trying to install a package, pressbooks/pb-cli, which is listed in the now-deprecated WP-CLI Package Index.
The current release of the package is 2.1.0 (corresponding to pressbooks/pb-cli@cc81de0). However, installing via the package command always installs the last release listed in the WP-CLI Package Index, which was 2.0.1 (corresponding to pressbooks/pb-cli@9fb35e6). If I try to specify the 2.1.0 version, I get the following error:
Describe how other contributors can replicate this bug
wp package install pressbooks/pb-cli
~/.wp-cli/packages/composer.lock
wp package uninstall pressbooks/pb-cli
wp package install pressbooks/pb-cli:2.1.0
Describe what you would expect as the correct outcome
As the package index is no longer being updated, I'd expect Packagist to be the higher priority repository.
Let us know what environment you are running this on
OS: Darwin 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
Shell: /bin/zsh
PHP binary: /usr/local/Cellar/php@7.4/7.4.20/bin/php
PHP version: 7.4.20
php.ini used: /usr/local/etc/php/7.4/php.ini
MySQL binary: /usr/local/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.5.9-MariaDB, for osx10.16 (x86_64) using readline 5.1
SQL modes: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /Users/ned/Sites/cli-test
WP-CLI packages dir: /Users/ned/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.5.0
Provide a possible solution
There could be a flag to explicitly bypass the WP-CLI Package Index.
Provide additional context
This also happens in GitHub Actions.
The text was updated successfully, but these errors were encountered: