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

Cannot install platform-specific wheels with non-python extension binaries on pip>=20.0.0 #7636

Closed
Korijn opened this issue Jan 22, 2020 · 7 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@Korijn
Copy link

Korijn commented Jan 22, 2020

Environment

  • pip version: 20.0.1
  • Python version: 3.6.4
  • OS: Windows 10 x64

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 or cffi. 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 providing ctypes 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:

  • glfw-1.10.1-py2.py3-none-macosx_10_6_intel.whl (99.8 kB)
  • glfw-1.10.1-py2.py3-none-manylinux2010_i686.whl (112.7 kB)
  • glfw-1.10.1-py2.py3-none-manylinux2010_x86_64.whl (118.4 kB)
  • glfw-1.10.1-py2.py3-none-win32.whl (496.5 kB)
  • glfw-1.10.1-py2.py3-none-win_amd64.whl (492.5 kB)
  • glfw-1.10.1.tar.gz (26.0 kB)

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

  • Install pip>=20.0.0
  • Use the installed version of pip to install glfw
  • Pip will install the source distribution (that doesn't contain the prebuilt binaries)

Or:

  • Force pip to install the wheel for your platform (i.e. for Windows x64 it's this link)
  • Wheel is not installed, and you see the error message ERROR: glfw-1.10.1-py2.py3-none-win_amd64.whl is not a supported wheel on this platform..

Output

$ pipenv install pip>=20.0.0
Creating a virtualenv for this project…
Pipfile: C:\Users\korij\dev\test\Pipfile
Using c:\users\korij\appdata\local\programs\python\python36\python.exe (3.6.4) to create virtualenv…
[  ==] Creating virtual environment...Already using interpreter c:\users\korij\appdata\local\programs\python\python36\python.exe
Using base prefix 'c:\\users\\korij\\appdata\\local\\programs\\python\\python36'
New python executable in C:\Users\korij\.virtualenvs\test-SUagSMsE\Scripts\python.exe
Installing setuptools, pip, wheel...done.

Successfully created virtual environment!
Virtualenv location: C:\Users\korij\.virtualenvs\test-SUagSMsE

$ pipenv run pip --version
pip 20.0.1 from c:\users\korij\.virtualenvs\test-suagsmse\lib\site-packages\pip (python 3.6)

$ pipenv run pip install glfw==1.10.1
Collecting glfw==1.10.1
  Downloading glfw-1.10.1.tar.gz (25 kB)
Building wheels for collected packages: glfw
  Building wheel for glfw (setup.py) ... done
  Created wheel for glfw: filename=glfw-1.10.1-py3-none-any.whl size=25667 sha256=29c3f9e8a609b0884a418d13ccbc7b2a9feae3e76a71276111e0673167f68487
  Stored in directory: c:\users\korij\appdata\local\pip\cache\wheels\a0\b4\23\11682f5036ba8a4d9711066c08be9325530f5330930b71b513
Successfully built glfw
Installing collected packages: glfw
Successfully installed glfw-1.10.1

$ pipenv run pip uninstall glfw
Found existing installation: glfw 1.10.1
Uninstalling glfw-1.10.1:
  Would remove:
    c:\users\korij\.virtualenvs\test-suagsmse\lib\site-packages\glfw-1.10.1.dist-info\*
    c:\users\korij\.virtualenvs\test-suagsmse\lib\site-packages\glfw\*
Proceed (y/n)? y
  Successfully uninstalled glfw-1.10.1

$ pipenv run pip install https://files.pythonhosted.org/packages/2a/f2/2d6381ae04caf456b63894278d875f3b6723aad895f0839c39e11e84b0d0/glfw-1.10.1-py2.py3-none-win_amd64.whl
ERROR: glfw-1.10.1-py2.py3-none-win_amd64.whl is not a supported wheel on this platform.

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.

@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Jan 22, 2020
@studioj
Copy link
Contributor

studioj commented Jan 22, 2020

having the same issue installing pyzbar on
windows 7 x64 python 2.7
windows 7 x64 python 3.7

@sbidoul
Copy link
Member

sbidoul commented Jan 22, 2020

Thanks for the detailed bug report. This looks like the same issue as #7626.

@burbigo1
Copy link

burbigo1 commented Jan 22, 2020

Yes, I think this issue has already existed, but I hope that it'll get fixed this time
TweakBox word counter Tutuapp

@rchen152
Copy link

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.

@Korijn
Copy link
Author

Korijn commented Jan 23, 2020

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?

@Korijn
Copy link
Author

Korijn commented Jan 23, 2020

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 :)

@Korijn Korijn closed this as completed Jan 23, 2020
@pradyunsg
Copy link
Member

Thanks @Korijn! 20.0.2 should have fixed this. :)

@pradyunsg pradyunsg removed the S: needs triage Issues/PRs that need to be triaged label Feb 21, 2020
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Apr 2, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Apr 2, 2020
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
Projects
None yet
Development

No branches or pull requests

6 participants