-
Notifications
You must be signed in to change notification settings - Fork 239
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
Mac OS wheels always fail testing: *.whl is not a supported wheel on this platform #1410
Comments
I have looked this over, and I don't understand this. So I tried running it locally, I ran: CIBW_BUILD_VERBOSITY=1 CIBW_BEFORE_TEST="python -m pip install pip --upgrade" CIBW_BEFORE_BUILD="python -m pip install pip --upgrade" CIBW_TEST_REQUIRES="pytest msgpack ruamel.yaml tomli tomli-w" CIBW_TEST_COMMAND="pytest {package}/test" pipx run cibuildwheel --only cp38-macosx_x86_64 It succeeded. Build log
Same result if I omit the pip-upgrading options. My build produced I notice that you're caching some pip stuff, maybe it'd be worth removing that? otherwise I'm stumped... |
I'm pretty sure it is connected with macos 12.0 and python 3.8. Could you try to skip the 3.8 version I do not have access to macOS machine but I remember that there were some problems with the generation of the list of supported platform tags for macos >= 11 and python 3.8 |
This is running though poetry and build.py, which I am not sure I trust. It should be just triggering the underlying setuptools build, though. There is no such thing as macOS 10.16. That's a non-existent compat version that you can get by setting a special variable. If you don't set it, you get 11.0 (or 12.0?) - maybe @joerick you've done that and saved it and forgotten about it? And is it not reading the correct MACOSX_DEPLOYMENT_TARGET setting? I'd agree with @Czaki, first see if you can get 3.9+ working, 3.8 was never officially supported by CPython so it's harder to do (edit: for Apple Silicon). It's also the built-in Python on macOS, so it's really nice to support it, though. |
Tried it on macos-11 and also doesn't work, however building on just Python 3.9+ does work! |
There is a reason why you do not compile it against some of 10.9-10.15 macos version? Or still, Poetry does not alow us to build against older macOS release? |
I don't use mac at all, but I assume using latest available would ensure best compatibility and support latest packages better? I want to target who is using it the most and I figured most people would be on newest versions. I can't use that old of mac version as github actions don't support it actions/runner-images#5583 |
Time to time apple breaks something, so it is normal that people wait up to half year writing until some special software is fixed. Maybe proper way is to build 3.9+ against 12.0 and 3.8 against 10.15.0 |
You want to try to target the oldest version your code builds on, so that you have the best chance of working - it should work on all newer systems. I'd recommend 10.9 if you don't use C++17, or 10.12-10.14 if you use C++17 (depending on how much you use). Most users are happy with 10.12, really, and these days, 10.15 is probably pretty safe. Apple drops support pretty quickly for older hardware, so there are machines that can't upgrade past 10.15 and even 10.12 (I have one stuck on 10.12, though I don't use it any more). Note that you do not use 10.12 or any such old version, you just target it with MACOSX_DEPLOYMENT_VERSION. You always use the latest macOS to build. Apple gates all new features by the library version that introduced support (and header only features always work!), so you just target old versions. Not use them to build. |
Is there a magic way to set it with
I see that it says it should be set in the docs https://cibuildwheel.readthedocs.io/en/stable/cpp_standards/#macos-and-deployment-target-versions but not an example of how to set it. And thank you for all the help and insight so far! This much already unblocks me! |
Nothing in my $ /Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 -m platform
macOS-10.16-x86_64-i386-64bit
Hmm, yeah, perhaps something in the Apple compiler toolchain changed in the runner images. But that wouldn't make sense if the problem happens in the macos-11 image, Xcode hasn't been updated there in 2 years.
That's the right place to put it, yeah. It doesn't necessarily set the wheel tag though, since your build might link in a library that's built targeting a newer OS. Or something has gone wrong and that variable isn't being respected. (another note- my spidey senses are telling me that there's some correlation between poetry builds and this variable not being respected, but I can't find a reference to that on the issue tracker...) |
@cdgriffith, could you try a couple things? In your CIBW_BEFORE_TEST, try putting
These give different results for me on my machine, just wanted to check this in CI also. That confuses me, as (I just learned in #1414) there is code in |
@joerick sorry for delay, had some fun capturing these https://gist.github.com/cdgriffith/562fc810cc6f585666a42c88aeb9e8c6 |
These are for Python 3.9, I thought you were having an issue with Python 3.8? |
Oh, yeah that would make sense to include the broken ones >.< https://gist.github.com/cdgriffith/44c5ea248b2272787a5e27a6f6047740 |
Yeah, that's what I'm getting, too. Having dug into this further, it looks to me that the Aside from that, I'm not really sure why this only affects Python 3.8. Older versions of Python 3.9 have the 10_16 behaviour, newer ones have the correct behaviour, so I think it's probably the SDK used to build, or a build-time flag. |
Thanks for your help! I raised an issue with pip about the error. If there's a reason you do need to target macOS 11+, you can set the env var Otherwise, it's a case of figuring out why your wheel is requiring such a new macOS. As @henryiii mentioned above, poetry seems like it would be a good place to look, here. |
There is a known issue with pip on Python 3.7 and 3.8 where [wheels can’t be installed on MacOS 11.0 or higher][pip-wheels], even if they were successfully built with on the same machine. This is causing our integration tests to fail in CI for these platforms. Apparently, the fix is to set the environment variable `SYSTEM_VERSION_COMPAT` to `0`, as in [this patch][fix]. The current patch enables this same environment variable. [pip-wheels]: pypa/cibuildwheel#1410 [fix]: gpongelli/pycode128@066cb37 Signed-off-by: Patrick M. Niedzielski <patrick@pniedzielski.net>
There is a known issue with pip on Python 3.7 and 3.8 where [wheels can’t be installed on MacOS 11.0 or higher][pip-wheels], even if they were successfully built with on the same machine. This is causing our integration tests to fail in CI for these platforms. Apparently, the fix is to set the environment variable `SYSTEM_VERSION_COMPAT` to `0`, as in [this patch][fix]. The current patch enables this same environment variable. [pip-wheels]: pypa/cibuildwheel#1410 [fix]: gpongelli/pycode128@066cb37 Signed-off-by: Patrick M. Niedzielski <patrick@pniedzielski.net>
There is a known issue with pip on Python 3.7 and 3.8 where [wheels can’t be installed on MacOS 11.0 or higher][pip-wheels], even if they were successfully built with on the same machine. This is causing our integration tests to fail in CI for these platforms. Apparently, the fix is to set the environment variable `SYSTEM_VERSION_COMPAT` to `0`, as in [this patch][fix]. The current patch enables this same environment variable. [pip-wheels]: pypa/cibuildwheel#1410 [fix]: gpongelli/pycode128@066cb37 Signed-off-by: Patrick M. Niedzielski <patrick@pniedzielski.net>
python3 -m pip install PySide6-6.7.0-cp39-abi3-macosx_11_0_universal2.whl ERROR: PySide6-6.7.0-cp39-abi3-macosx_11_0_universal2.whl is not a supported wheel on this platform. I see all these comments and I am still unsure on how to install the wheel file? |
What is your pip version? Try |
Hi Henry, cp39-abi3-macosx_11_0_universal2 is not showing up there. |
What pip version? |
pip 24.0 and python 3.9
|
Description
I have tried creating wheels for mac via github actions on both macos-11 and macos-12 and always run into the same issue, that it creates the wheel and when it tries testing them, it gets the error:
Work is being done on this develop branch currently https://github.com/cdgriffith/Box/tree/develop
Have tried both just
x86_64
anduniversal2
builds and always seems to build and test anx86_64
version that it then fails on. Made sure to do a manual pip update inside the test env itself withCIBW_BEFORE_TEST: "python -m pip install pip --upgrade"
as well as others have had issues with outdated pip versions (locally, not withcibuildwheel
)Build log
https://gist.github.com/cdgriffith/5afcf8db84dfa07b6e833eafcefd2dbe
CI config
https://github.com/cdgriffith/Box/blob/develop/.github/workflows/tests.yml
The text was updated successfully, but these errors were encountered: