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

Comments

@mwilliamson
Copy link
Contributor

commented May 4, 2018

  • 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

This comment has been minimized.

Copy link
Member

commented May 6, 2018

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 triage label May 6, 2018

@mozbhearsum

This comment has been minimized.

Copy link

commented May 31, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2018

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

@cjerdonek

This comment has been minimized.

Copy link
Member

commented May 24, 2019

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

@cjerdonek

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

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

@pradyunsg

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

Thanks for working on this @cjerdonek! :-)

@lock lock bot added the S: auto-locked 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.
Projects
None yet
5 participants
You can’t perform that action at this time.