[2020-resolver] No longer can get list of available versions.

What did you want to do?

I would like to list all the available versions of a package. In the past we would use this:

pip install pip==asdf  # any gibberish here :)

Output

ERROR: Could not find a version that satisfies the requirement pip==asdf
ERROR: No matching distribution found for pip==asdf

expected output (pip==20.2.4)

ERROR: Could not find a version that satisfies the requirement pip==asdf (from versions: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 
0.5, 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.8.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 
1.2.1, 1.3, 1.3.1, 1.4, 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 
6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.1.0, 6.1.1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.1.2, 8.0.0, 8.0.1, 8.0.2, 
8.0.3, 8.1.0, 8.1.1, 8.1.2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 10.0.0b1, 10.0.0b2, 10.0.0, 10.0.1, 18.0, 18.1, 19.0, 
19.0.1, 19.0.2, 19.0.3, 19.1, 19.1.1, 19.2, 19.2.1, 19.2.2, 19.2.3, 19.3, 19.3.1, 20.0, 20.0.1, 20.0.2, 20.1b1, 
20.1, 20.1.1, 20.2b1, 20.2, 20.2.1, 20.2.2, 20.2.3, 20.2.4, 20.3b1)

Additional information

• Using verbose flag: pip install -v pip==asdf we can sorta see that versions. (300 line output, too long to post here) Seems like no extra requests needed. I wasn’t 100% sure if it was the case.
• This is useful when debugging failed installation of a requirement.txt, pipenv or other 3rd party package managers

[wimglenn]

This was not a useful error message for people who UNINTENTIONALLY got it

@brainwane I disagree with that, actually it’s still useful even when UNINTENTIONALLY getting it. If I did pip install distlib==0.29.post0 and saw:

ERROR: Could not find a version that satisfies the requirement distlib==0.29.post0
(from versions: 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.2.0, 0.2.1, 
0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8, 0.2.9, 0.2.9.post0, 0.3.0, 0.3.1)

That tells me I just had a silly typo and I wanted 0.2.9.post0. But if I saw

ERROR: Could not find a version that satisfies the requirement distlib==0.29.post0 (from versions: none)

It tells me something else, probably that I have misconfigured my index urls and I should check the pip config. In 20.3.x

ERROR: Could not find a version that satisfies the requirement

This is less helpful again. Is my index misconfigured? Could it find any version at all? Do I just need to wait a moment or clear pip’s cache - maybe I just published this package recently?

pip search afaik is broken and slated to be removed (https://github.com/pypa/pip/issues/5216). At least, I could not find any way to use it reliably (and couldn’t get it working at all with a devpi-server index).

Thank you for mentioning the --use-deprecated=legacy-resolver option! For the purposes of keeping the project johnnydep functioning on pip 20.3.x, this helped for now. Currently it scrapes pip’s CLI output in a way that needs careful tweaking and testing each time a new version of pip is released. So here’s a bit of UX feedback, it would be really nice if there was a less fragile way to get:

• download urls
• package dependencies
• versions available

It’s definitely not (and never was) a supported way of getting that information.

@pfmoore So how do we get that information? A while ago pip moved all package finding code under _internal and made it explicit that a CLI subprocess was the only supported way to use pip from your program. This is arguably an important part of the CLI.

it’s not that hard to write something yourself that gets the same information, using the PyPI JSON

I think that is oversimplifying the problem. It might be true if pip was only a PyPI client, but it’s a lot more than that isn’t it? Pip’s the de facto tool for working with Python packages, whether from PyPI or not, since we don’t really have one in the stdlib.

To repeat again the points in #1884: the PyPI JSON is not in general “the same information” because where pip looks is highly configurable, e.g. we may have another --index-url and then an --extra-index-url and maybe that index is just a simple repository which is supporting a JSON api at all. There are a lot of little details here and doing it in a way that accurately produces the same packages that pip would see would mean reproducing a significant amount of package finder code found within pip._internal.

[RafalSkolasinski]

I believe that at this point this is just a behaviour that many people may have relied on for years. Sometimes things that were not meant to be present but were just become part of what is expected.