-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Failure to install manylinux1 wheel from manylinux1 docker image (Centos5) when a newer manylinux2010 wheel is available #6547
Comments
To troubleshoot the "it is not compatible with this Python" log messages you're getting above, can you try running the following code on your system? from pip._internal.pep425tags import get_supported
print('\n'.join('-'.join(x) for x in get_supported())) This will tell you what tags pip is using to find matches against. Also, here's another related issue: #6526 |
Thanks for the quick follow up 🙏 Here it is:
|
Just to be sure, that looks like a different pip from the one above you used to reproduce the error:
|
Good catch. I edited the original description to be consistent and mention 36 instead of 37. The difference in path is explained by the fact
Here is the same command running using python 3.6:
Worth noting that while the manylinux1 wheel is evaluated as valid by CandidateEvaluator.evaluate_link():
the sdist for the newer version of the package ends up being installed. |
Arff ... it looks like passing this option:
avoids the issue. |
Okay, thanks. In the "Detailed Output" section of your original report, it says--
But with your second invocation you were getting different output (that was compatible)? It would be good to update the detailed output in the original report if that was for a different version. |
Okay, so that does that mean there isn't actually an issue anymore? Is there something that could have helped here? |
Indeed, while the 686 wheel is skipped, the one x68_64 was not. I just updated the regex use to filter the output to make this obvious in the detailed output.
Indeed, passing
With the transition to manylinux2010, I anticipate build relying on binary wheels will start exerting a similar behavior (as expected), if such condition is detected I wonder if a warning could be reported. Alternatively, I wonder if This would streamline the user experience while providing a path forward. |
Okay, glad it got sorted out. Do you think you could open a new issue with your suggestions if you think there are some tweaks worth considering (e.g. warnings, changes in defaults, etc)? |
Thanks again for the help, I created an issue with possible approaches and suggestion. Now closing this report. |
Environment
Description
Attempt to install a wheel from
manylinux1
docker image (Centos 5) should successfully install an oldermanylinux1
wheel instead of trying to build the latest one from source that is only available formanylinux2010
.Expected behavior
If the following sdist and wheels are available:
Trying to
pip install cmake
from amanylinux1
system (using python 3.6) should successfully installcmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl
.Additional remarks
Running
pip install cmake<3.14
successfully installcmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl
Starting with
cmake 3.14
, we changed the tags of the binary wheel to be ABI independent, this was suggested by @njsmith in Add Python 3.8.0a2 manylinux#273 (comment) to avoid building one wheel per python release.cmake-3.13.3-cp36-cp36m-manylinux1_x86_64.whl
# specific to Python 3.7 ABIcmake-3.14.4-py3-none-manylinux2010_x86_64
# platform specific but genericHow to Reproduce
manylinux1_x86_64
imageOutput
Detailed Output
Issue potentially related
The text was updated successfully, but these errors were encountered: