Pip: `pip` downlads and tries to install a wrong wheel

Created on 1 Mar 2020  路  4Comments  路  Source: pypa/pip

Environment

  • pip version: 9.0.1
  • Python version: 2.6.9
  • OS: Ubuntu

https://travis-ci.org/tomerfiliba/plumbum/jobs/656956382

Description
The build pypeline deals with an obsolete and deprecated version of python. It installs coveralls, which depends on urllib3, which depends on idna>=2.0.0. Support of 2.6 has been dropped in idna 2.8.

Expected behavior
pip should download the latest version that supports the used version of the language.

How to Reproduce
Likely to try to install a package with --upgrade which latest version requires the version of the language other than the used one.

Output

idna requires Python '>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*' but the running Python is 2.6.9
python 2 only invalid auto-locked awaiting response

Most helpful comment

Can you reproduce the issue you're reporting in a supported version? If so, please provide a minimal example and we can look into it.

The data-requires-python tag on the index (see PEP 503) avoids downloading (some) incompatible files. Wheel tags avoid some others. But ultimately some metadata is only checked after the install with the current resolver. This will be addressed with the new resolver.

All 4 comments

This version of pip and the version of Python are both unsupported. The problem is likely the lack of support for Python-Requires metadata, but that's not going to be backported, so the response here is simply that you should upgrade.

This version of pip and the version of Python are both unsupported.

The problem is likely the lack of support for Python-Requires metadata, but that's not going to be backported, so the response here is simply that you should upgrade.

Is this problem solved? I mean do pip+warehouse have a mechanism to allow pip download wheels only of versions supported by its python? I mean I can imagine only 1 sensible variant of this mechanism: pip downloads the whole history of versions via API, consisting of requirements for every version and its ID, analyses it, selects the version, downloads it.

Another possible mechanism is: pip reports "I want the version for this python", warehouse selects it and returns it, but this mechanism is limited, it doesn't allow to select on other packages versions without uploading the info about installed packages to the server, which is inacceptable, it's only pro is that it is 1 HTTP request less.

So does pip have any mechanism for selecting and downloading the wheel matching the constraints written in the wheel itself?

Can you reproduce the issue you're reporting in a supported version? If so, please provide a minimal example and we can look into it.

The data-requires-python tag on the index (see PEP 503) avoids downloading (some) incompatible files. Wheel tags avoid some others. But ultimately some metadata is only checked after the install with the current resolver. This will be addressed with the new resolver.

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Was this page helpful?
0 / 5 - 0 ratings