-
Notifications
You must be signed in to change notification settings - Fork 267
Tag macosx_10_9_universal2 not accepted when running native arm64 (on macOS 11) #379
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
Comments
I think PR pypa/wheel#390 is related, but I'm not sure to which extend. Maybe @ronaldoussoren knows off the top of his head what is going on here? |
pypa/wheel#390 is for creating wheels, so this is not related. Can you try what this prints for you? from pip._vendor.packaging.tags import cpython_tags
for t in cpython_tags(): print(str(t)) You may want to report this to https://github.com/pypa/packaging instead (which pip uses underneath, and this error is emitted if pip detects a tag not recognisable by the library); you’d more easily get attention from people with relevant knowledge there. |
Could you also provide the output of |
I'll ping pypa/packaging then, thanks! |
Actually if anyone with write permissions on pypa/packaging would transfer this issue, we could skip the duplicate. I'll wait an hour or so now before opening another issue over there. |
How are you getting the 10_9 tag for the universal2 wheel? |
For the actual wheel I was looking at: I was building it through the standard toolchain |
That said, getting the 10_9 platform tag was my expectation -- I wanted a binary wheel whose x86_64 portion would be compatible down to macOS 10.9 and whose arm64 portion would run on all supported versions too (which currently only is 11.X...) |
Using a recentish version of wheel and the universal2 build of CPython. I don't have a link to the relevant PR at hand, but the basic idea is that a "macosx_10_9_universal2" wheel will work on all mac systems with an x86_64 or arm64 CPU running macOS 10.9 or later. |
Ah. No one has updated packaging.tags for this change in CPython yet, so I'd request someone familiar with the situation to go ahead and file a PR for this. :) |
I would have expected that #319 would have done the trick, but apparently not. I just received my M1 system and am currently geeking on on configuring it. What I don't quite understand is that I guess its time to clone the repo and try to understand what's going on here. |
We're basically using the tags from this package as-is. Running |
|
The attached PR should fix the issue. When I replace the copy of packaging in pip._vendor by the patched version in the PR "pip debug -v" shows the expected output and "pip install pyobjc-core" uses the universal2 wheel to install. |
Independently discovered by @joerick in pypa/cibuildwheel#484 as well. |
Environment
Description
Running the arm64 portion of Python 3.9.1 to install a universal2 binary wheel ("macosx_10_9_universal2" is the default tag) fails. On contrary, using the x86_64 portion of the very same binary the installation succeeds. For me the expected behaviour is that such wheels can be installed with both the arm64 and x86_64 portions on macOS 11.
The offending portion that pip rejects is the
10_9
part. If I manually rename this portion of the wheel file to11_0
, the installation succeeds. Again, for me the expected behaviour is that such wheels can be installed on macOS 11What did you want to do?
Install a universal2 binary wheel on macOS 11 using Python 3.9.1. Simplified setup using a dummy wheel:
Output
Additional information
Using the x86_64 portion, the wheel tag is accepted (and we get the expected error from using a dummy wheel):
Version of the interpreter, showing that the system platform matches the wheel tag:
Version of installed packages:
The text was updated successfully, but these errors were encountered: