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

pip download --python-version fails when downloaded package doesn't support the Python version running pip #5369

Closed
mwilliamson opened this issue May 4, 2018 · 6 comments · Fixed by #6577
Labels
auto-locked Outdated issues that have been locked by automation C: download About fetching data from PyPI and other sources type: bug A confirmed bug or unintended behavior

Comments

@mwilliamson
Copy link
Contributor

  • Pip version: 10.0.1
  • Python version: 2.7
  • Operating system: Linux (Debian)

Description:

I'm using pip download to download packages for a different version of Python than the version that pip is running on. Specifically, I'm using pip on Python 2.7 to download packages for Python 3.5. The wheel for Python 3.5 is downloaded successfully, but pip download exits with an error since the wheel specifies a minimum Python version of 3.4.

Setting ignore_requires_python=True in pip/_internal/commands/download.py turns the error into a warning (which still isn't ideal), but would the proper fix be for check_requires_python to consider the Python version passed to the download command?

What I've run:

$ pip download python-rapidjson --dest . --no-deps --platform manylinux1_x86_64 --python-version 35 --implementation cp --abi cp35m
Collecting python-rapidjson
  File was already downloaded /tmp/py/python_rapidjson-0.5.2-cp35-cp35m-manylinux1_x86_64.whl
python-rapidjson requires Python '>=3.4' but the running Python is 2.7.9

With verbose output, the last part of the output is:

  Downloading from URL https://files.pythonhosted.org/packages/44/59/70b5060b7a5afaec36cdb618dd1c59a389642e739a49b76fef81446f18f8/python_rapidjson-0.5.2-cp35-cp35m-manylinux1_x86_64.whl#sha256=d20ca8dfd9db296941c1f978231ddf9402494c868ae8d6e431b59c8406063cad (from https://pypi.org/simple/python-rapidjson/)
  Saved ./python_rapidjson-0.5.2-cp35-cp35m-manylinux1_x86_64.whl
python-rapidjson requires Python '>=3.4' but the running Python is 2.7.9
Exception information:
Traceback (most recent call last):
  File "/home/michael/apps/virtualenv/local/lib/python2.7/site-packages/pip/_internal/basecommand.py", line 228, in main
    status = self.run(options, args)
  File "/home/michael/apps/virtualenv/local/lib/python2.7/site-packages/pip/_internal/commands/download.py", line 221, in run
    resolver.resolve(requirement_set)
  File "/home/michael/apps/virtualenv/local/lib/python2.7/site-packages/pip/_internal/resolve.py", line 103, in resolve
    self._resolve_one(requirement_set, req)
  File "/home/michael/apps/virtualenv/local/lib/python2.7/site-packages/pip/_internal/resolve.py", line 262, in _resolve_one
    check_dist_requires_python(dist)
  File "/home/michael/apps/virtualenv/local/lib/python2.7/site-packages/pip/_internal/utils/packaging.py", line 55, in check_dist_requires_python
    '.'.join(map(str, sys.version_info[:3])),)
UnsupportedPythonVersion: python-rapidjson requires Python '>=3.4' but the running Python is 2.7.9
@pradyunsg
Copy link
Member

I'm personally not sure what's supposed to happen here. I'm not familiar with Python-Requires behaviors.

Maybe someone else from @pypa/pip-committers is.

@pradyunsg pradyunsg added the S: needs triage Issues/PRs that need to be triaged label May 6, 2018
@bhearsum
Copy link

I was surprised by this behaviour as well. I'm trying to use "pip download" to gather required packages for deployment elsewhere, and this makes it extremely difficult to do so.

It's odd that "pip download" is inconsistent here -- it pays attention to python version in the PackageFinder, but not here.

@xavfernandez xavfernandez added type: bug A confirmed bug or unintended behavior C: download About fetching data from PyPI and other sources and removed S: needs triage Issues/PRs that need to be triaged labels Oct 8, 2018
@xavfernandez
Copy link
Member

I'd say this is a valid bug: pip should not check Python-Requires in this case.

@cjerdonek
Copy link
Member

cjerdonek commented May 24, 2019

I posted PR #6528, which will help with this issue.

@cjerdonek
Copy link
Member

FYI, I posted PR #6577 to address this issue.

@pradyunsg
Copy link
Member

Thanks for working on this @cjerdonek! :-)

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jul 7, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jul 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: download About fetching data from PyPI and other sources type: bug A confirmed bug or unintended behavior
Projects
None yet
5 participants