Repository navigation
Legacy package index prevents installation of current release of a package #141
Description
Bug Report
- Yes, I reviewed the contribution guidelines.
- Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.
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:
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 - Observe that the installed version is as follows:
"name": "pressbooks/pb-cli",
"version": "dev-master",
"source": {
"type": "git",
"url": "https://github.com/pressbooks/pb-cli.git",
"reference": "9fb35e6129bbf51b53408671edce9bee5b75964d"
}
}- Run:
wp package uninstall pressbooks/pb-cli - Run:
wp package install pressbooks/pb-cli:2.1.0 - Observe the error that ensues:
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.
Activity
selul commentedon Jul 14, 2021
Might be solved if we set the WP-CLI Package Index as non-canonical, i.e
canonical: false, more details about this hereI can help to send a PR if this is a good idea.
aaemnnosttv commentedon Sep 12, 2021
@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.jsonto mark the wp-cli composer repository ascanonical: false, if I runwp package list, the resulting output correctly reports that an update is now available where it wasn't before.However, running
wp package updatestill 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
packagistto the list of repositories beforewp-clifixed the problem for me (as my packages are all listed on Packagist (as ispressbooks/pb-cli).{ "name": "wp-cli/wp-cli", "description": "Installed community packages used by WP-CLI", "version": "2.5.0", "authors": [ { "name": "WP-CLI", "email": "noreply@wpcli.org" } ], "homepage": "https://wp-cli.org/package-index/", "require": { "aaemnnosttv/wp-cli-dotenv-command": "dev-master" }, "require-dev": {}, "minimum-stability": "dev", "prefer-stable": true, "license": "MIT", "repositories": { + "packagist": { + "type": "composer", + "url": "https://repo.packagist.org/" + }, "wp-cli": { "type": "composer", "url": "https://wp-cli.org/package-index/" } }, "config": { "secure-http": true } }If we had
wp-clias 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-clirepository to usecanonical: falseanyways 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.