-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
Switch macos x86_64 to macos14 in generate-ci #2246
Conversation
The macos12 images [are deprecated and will be decommissioned by december](actions/runner-images#10721), jobs have started triggering warnings and brownouts are planned. In my understanding this means the x86_64 wheels will be cross-compiled from the arm64 runners, but I understand cross compilation works fine. The x86_64 cross compilation is slower than the ARM64 compilation, but on my test project it's faster than the macos13 x86_64 build so that doesn't seem like a massive concern I feel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, note that pytest
step also needs adjustment because you can't run tests for x86_64 wheels on aarch64 macOS after this change.
Ah good catch, I assumed either arm64 or x86_64 python would be installed and then that's what would be run, but not so, and it's not even a question of enabling From my testing it looks like |
That may not work with pypy I think, they don't have universal2 binaries: https://pypy.org/download.html From https://github.com/actions/python-versions/releases/tag/3.13.0-11228081754 I didn't find any universal2 python distributions. |
So should probably pass the architecture to $ arch -x86_64 graalpy-24.1.0-macos-aarch64/bin/graalpy
arch: posix_spawnp: graalpy-24.1.0-macos-aarch64/bin/graalpy: Bad CPU type in executable
The note about universal binaries is in the readme: https://github.com/actions/python-versions/tree/3.13.0-11228081754?tab=readme-ov-file#building-installation-packages The x86_64 and amd64 assets bundle the exact same thing: $ sha1sum python-3.13.0-darwin-x64/python-3.13.0-macos11.pkg
1c1e6e6cf6370ff8020fb7b93a8b408f23d65054 python-3.13.0-darwin-x64/python-3.13.0-macos11.pkg
$ shasum python-3.13.0-darwin-arm64/python-3.13.0-macos11.pkg
1c1e6e6cf6370ff8020fb7b93a8b408f23d65054 python-3.13.0-darwin-arm64/python-3.13.0-macos11.pkg |
Right, but note that it's only for Python >= 3.11. |
Sure but generate-ci creates a template for 3.x so that's been >= 3.11 since it was created. Though if we pass the architecture to setup-python for the benefit of pypy and graal it should get picked up for cpython < 3.11 and retrieve arch-specific payloads, and like pypy and graal the I'll try that out to make sure it works. |
Well apparently it doesn't, python < 3.11 x64 seems broken on M1: https://github.com/masklinn/ci-test/actions/runs/11296863554/job/31422564472 I'll have to see with the setup-python people if they know why. edit: opened actions/setup-python#960 |
Welp, apparently action/setup-python has decided not to fix the non-universal python images, so not quite sure what to do there, I guess I'll close this.? |
Close for now, we have switched to macos-13. |
The macos12 images are deprecated and will be decommissioned by december, jobs have started triggering warnings and brownouts are planned.
In my understanding this means the x86_64 wheels will be cross-compiled from the arm64 runners, but I understand cross compilation works fine. The x86_64 cross compilation is slower than the ARM64 compilation, but on my test project it's faster than the macos13 x86_64 build so that doesn't seem like a massive concern I feel?