-
Notifications
You must be signed in to change notification settings - Fork 234
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
macos/py38/arm: wheels tagged 10_16 for MACOSX_DEPLOYMENT_TARGET=12 #1414
Comments
Also broken under v2.11.4. https://github.com/scikit-image/scikit-image/actions/runs/4117077160/jobs/7107935610 |
Same problem on v2.10.2. https://github.com/scikit-image/scikit-image/actions/runs/4117218052/jobs/7108250063 |
Also not working with latest HEAD, fwiw: https://github.com/scikit-image/scikit-image/actions/runs/4118133692/jobs/7110290899 |
does exporting environment variable SYSTEM_VERSION_COMPAT=0 help ? |
That does fix it! 🎉 https://github.com/scikit-image/scikit-image/actions/runs/4121828219/jobs/7117902113 So, what is this black magic, and is it safe to use it? I don't see it anywhere in the docs. |
The black magic is explained in there (& mostly the related issue): pypa/packaging#513
As mentioned in the PR linked, there are absolutely no docs from Apple for this (at least at that time) so other possible side effects are unknown... The safest would be to track down which package in the build system tries to label this wheel as 10.16 & ask them to either respect MACOSX_DEPLOYMENT_TARGET and/or read the macOS version with SYSTEM_VERSION_COMPAT=0 set (as done in |
given your build only targets arm64 macOS 12+ & runs on macOS-12, maybe installing manually cpython 3.8 universal2 would lead to the same outcome without the need to export SYSTEM_VERSION_COMPAT or track down which package is labelling the wheel 10.16 in the first place. c.f. https://cibuildwheel.readthedocs.io/en/stable/faq/#macos-building-cpython-38-wheels-on-arm64 |
From https://eclecticlight.co/2020/08/13/macos-version-numbering-isnt-so-simple/
So, what I'd expect is for the default to be correct, and to have to invoke Either way, building without emulation is preferable, so I'm trying out the other route as well. |
Excellent. Build time went from 12 to 8 minutes, and the wheel is correctly tagged. Thanks very much @mayeut! |
This speeds up the build, and also ensures that the correct wheel tag is applied. - pypa/cibuildwheel#1414 - https://cibuildwheel.readthedocs.io/en/stable/faq/#macos-building-cpython-38-wheels-on-arm64
This speeds up the build, and also ensures that the correct wheel tag is applied. - pypa/cibuildwheel#1414 - https://cibuildwheel.readthedocs.io/en/stable/faq/#macos-building-cpython-38-wheels-on-arm64
Description
While building scikit-image 0.20rc4, we noticed that (only) our Python 3.8 MacOS wheel gets tagged incorrectly as 10_16 instead of as 12_0.
The cibuildwheel history shows that this version sometimes comes up when using macos 11 (although our build image is 12).
Example build logs can be seen here:
For an example of a successful build, see e.g. the one for py39 at https://github.com/scikit-image/scikit-image/actions/runs/4110960293/jobs/7094258456:
Any ideas of why py38 would behave differently?
Build log
https://pipelines.actions.githubusercontent.com/serviceHosts/40f46268-6c19-4e51-9405-da082fc91a36/_apis/pipelines/1/runs/10844/signedlogcontent/19?urlExpires=2023-02-07T06%3A47%3A18.4042231Z&urlSigningMethod=HMACV1&urlSignature=xwWdIpUSdnztqH4bZ1eTjr2X5eA3QBYlhlVYz0a%2Fl48%3D
CI config
https://github.com/scikit-image/scikit-image/blob/main/.github/workflows/wheel_tests_and_release.yml
The text was updated successfully, but these errors were encountered: