pip: pip download --platform --python-version does not work for some packages

Environment

  • pip version: 18.0
  • Python version: 2.7
  • OS: centos 7

Description

When using pip to download wheels for it does not find them despite the fact that there are obvious matches available on PyPI

How to Reproduce

I tried all of the following commands <and many other permutations) to try to make this work

pip download --python-version 36 --abi cp36 --platform linux_x86_64  "hiredis==0.3.1" --only-binary=:all: --dest ./wheelhouse -v
pip download --python-version 36 --abi cp36 --platform manylinux1_x86_64  "hiredis==0.3.1" --only-binary=:all: --dest ./wheelhouse -v
pip download --python-version 36 --abi cp36 --platform linux_x86_64  --implementation py "hiredis==0.3.1" --only-binary=:all: --dest ./wheelhouse -v
...
    Skipping link https://files.pythonhosted.org/packages/0d/d1/f0346030e4e5fbd931c7d81acdb8c81ea57733f6d87bc15f3dc28a51eb30/hiredis-0.3.1-cp36-cp36m-manylinux1_x86_64.whl#sha256=736a30992ede64b79989869e1a068fec93405dac71d87a316f22ee72e75cb6a5 (from https://pypi.org/simple/hiredis/) (requires-python:>=2.6, !=3.0.*, !=3.1.*); it is not compatible with this Python
...
No matching distribution found for hiredis==0.3.1

The wheel it skips looks perfectly valid to me: hiredis-0.3.1-cp36-cp36m-manylinux1_x86_64.whl . I assume linux_x86_64 matches manylinux1_x86_64, and even if it doesn’t, I tried specifiying manylinux1_x86_64 just to be safe.

The same thing happens when trying to download wheels for python 2.7.

The documentation on how these work together is pretty sorely lacking (

  • what is the valid list of platforms and what is the logic for how they match?
  • the provided examples about macosx use the wrong specifier, AFAICT, using a dash instead of an underscore.
  • the pep that is referred to is far too long to grok and it also seems out of date
  • the verbose output about the skipped wheels above provides no information about how pip came to the conclusion that the wheel “is not compatible with this Python”. It would be nice if the note provided some more info about why the wheel is not considered compatible.

Along with the other issue I posted #5369 it feels like the intersection of what is required to be useful and what actually works is frustratingly small.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 7
  • Comments: 15 (11 by maintainers)

Commits related to this issue

Most upvoted comments

I’m not sure I understand the nuances here well enough, but if it is indeed simple enough to file an implementation PR, please feel free to do so. It’ll even bring us to a nice round number of 80 open PRs. 😛

I wonder if the most straightforward patch here could be to augment the semantics of --platform and --abi flags, to accept comma-separated lists of acceptable values?

Looking at get_supported(), and given that the underlying functions from packaging.tags already accept Iterable[str] for both abis and platforms, this looks like it could be a minor (and non-breaking?) change.

We could then invoke

pip download \
    --python-version 36 \
    --abi "cp36m,cp36,abi3,none" \
    --platform "manylinux2014_x86_64,manylinux2010_x86_64,manylinux1_x86_64,linux_x86_64,any" \
    --no-deps hiredis==0.3.1

which, while a bit less than ideal, might at least get us the right .whl from a single command. Thoughts?