Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
pip download --platform --python-version does not work for some packages #6121
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
The wheel it skips looks perfectly valid to me:
The same thing happens when trying to download wheels for python 2.7.
The documentation on how these work together is pretty sorely lacking (
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.
I would just like to mention that I am also running into this issue on CentOS while trying to download MacOS wheels. This issue appears to also be reproducible for both Ubuntu and CentOS via Docker. For Ubuntu:
# create a docker container $ docker run -it ubuntu bash
# install pip and try to download a macos package $ apt-get update $ apt-get install -y python3 python3-virtualenv $ python3.6 -m virtualenv --python=python3.6 env $ ./env/bin/python3.6 -m pip install -U pip $ ./env/bin/python3.6 -m pip download --only-binary :all: --platform macosx_10_10_intel --python-version 27 --abi cp27 -v numpy==1.16.0
And the snipped output from pip:
These steps on CentOS have the same result:
Note that it still seems to exhibit this behavior even if you are actually running under CPython 2.7 (but on Linux instead of MacOS). The packages download without issue when running the same command on MacOS.
Was trying pip download and had some very similar issues. The documentation was not super useful, but after some trial and error, the command that got it working for me for hiredis is:
Similarly, for the numpy example, changing the abi to cp27m works for me:
Pretty much got this via trial and error ... Better documentation would be really helpful
FYI, I just posted PR #6540 to address this portion of the original comment:
I was thinking more about this because #6540 only provides half of the information (namely the wheel's file tags). Currently, I don't think there's any way for the user to know the other half of the information -- namely what tags the current Python version matches (or the requested version in the case of options like
I was thinking then that a new command called something like
Maybe later the command could accept arguments for things like evaluating certain wheel filenames against the current Python version, with more verbose logging, etc. The command could be thought of as a helper for working with PEP 425 compatibility tags as implemented by pip: https://www.python.org/dev/peps/pep-0425/#details
FYI, yesterday I posted PR #6638 that will help with this. It implements an initial
So combined with PR #6540 (already merged), this would give you a better pathway to troubleshoot issues like the ones in this issue. Namely, with PR #6540 merged, the logs will tell you for each wheel what tags the wheel generates. And PR #6638 would give you an interactive way to see whether you can generate any of those tags (and locally, without having to do any actual installs, etc).
I have a similar issue but more related to that it does not recognize --python-version 36 as being python >3.5. This leads pip to download an older version, for example when trying to download numpy:
I get a whole list of output, stating that version 1.16.4 is the newest version available for this version of python, despite the fact that version 1.17.0 is available for python 3.6.
It does accept 1.16.4 because the versions accepted are all != tests:
However, python version >=3.5 is not accepted when --python-version=36:
Which seems like an error to me but maybe I'm mistaken. The same issues occur for pandas (downloads 0.24.2 instead of 0.25.0) and scipy (downloads 1.2.2 instead of 1.3.1).