pip download --platform --python-version does not work for some packages
See original GitHub issueEnvironment
- 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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:7
- Comments:15 (11 by maintainers)
Top GitHub 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 frompackaging.tags
already acceptIterable[str]
for bothabis
andplatforms
, this looks like it could be a minor (and non-breaking?) change.We could then invoke
which, while a bit less than ideal, might at least get us the right
.whl
from a single command. Thoughts?