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

Legacy package index prevents installation of current release of a package #141

Open
2 tasks done
greatislander opened this issue Jun 30, 2021 · 2 comments
Open
2 tasks done

Comments

@greatislander
Copy link

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:

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.

@selul
Copy link

selul commented 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 here

I can help to send a PR if this is a good idea.

@aaemnnosttv
Copy link
Contributor

@selul I've been looking into this too and it looks like using canonical: false should 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).

 {
     "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-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.

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

No branches or pull requests

4 participants