-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Cannot install platform-specific wheels with non-python extension binaries on pip>=20.0.0 #7636
Comments
having the same issue installing pyzbar on |
Thanks for the detailed bug report. This looks like the same issue as #7626. |
Yes, I think this issue has already existed, but I hope that it'll get fixed this time |
I believe we're experiencing the same problem with ninja (google/pytype#495). Instead of installing one of the wheels, pip is trying to install the source distribution, which fails with an import error. |
For anyone else reading this, looks like it may have been fixed upstream here: pypa/packaging#258 Now pip just needs to update their vendored version I think? |
I'm quite certain this will be tracked and solved via #7626 so I will close this issue to save the maintainers some cognitive load :) |
Thanks @Korijn! 20.0.2 should have fixed this. :) |
Environment
Description
It is no longer possible to install platform-specific wheels with non-python extension binaries on pip>=20.0.0. These are wheels that include prebuilt binaries for specific platforms, and ship a Python wrapping layer using for example
ctypes
orcffi
. There is no Python extension, so the wheels are not tied to a specific python version or implementation. The only constraint for these wheels is the platform (OS) and architecture (32 vs 64 bit) because of the prebuilt binaries they ship with.I'll use
glfw
as an example here, but there are certainly others out there.glfw
is a package providingctypes
wrappers for prebuilt binaries that are included in the wheel as well. As you can see on their PyPI page, they provide the following packages:The platform tags we see here make sense to me: neither the prebuilt binaries contained within the wheels, nor the python wrappers need to be pinned to a specific python implementation, so 'py2.py3-none' is accurate. The binaries are restricted to a specific platform, so we do see separate wheels for each of those (
win32
,win_amd64
,manylinux2010_x86_64
, etc). This is correct and used to be working.When I try to install with pip>=20.0.0, it will select the source distribution, and alternatively forcing to install the wheel will fail with the error message
ERROR: glfw-1.10.1-py2.py3-none-win_amd64.whl is not a supported wheel on this platform.
. Also see "reproduction" below.After going through the release notes, I am inclined to think the issue is caused by the recently merged #7354
Expected behavior
Pip<20.0.0 behavior: the most compatible wheel is selected and installed by pip.
How to Reproduce
Or:
ERROR: glfw-1.10.1-py2.py3-none-win_amd64.whl is not a supported wheel on this platform.
.Output
Just wanted to finish this bug report by saying thank you for all your hard work. If possible, I'm willing to help resolve this problem, but I think I should wait to see the response here before I dive in.
The text was updated successfully, but these errors were encountered: