MAINT, BLD: Wheel CI: Update cibuildwheel to 2.11.2 #22524
Conversation
.github/workflows/wheels.yml
Outdated
| - [macos-10.15, macosx_*] | ||
| - [windows-2019, win_amd64] | ||
| - [windows-2019, win32] | ||
| - [ubuntu-22.04, manylinux_x86_64] |
There was a problem hiding this comment.
These are all risky changes. The choice of windows-2019 was deliberate, also macosx. Ubuntu probably doesn't matter.
It would be best to do one thing at a time, update cibuildwheel, for instance :)
There was a problem hiding this comment.
@h-vetinari Where is condo on versioning at this point?
There was a problem hiding this comment.
@h-vetinari Where is conda on versioning at this point?
There's a couple of things to consider. For windows, there's three related but separate things: the image, the visual studio version and the actual toolchain version. The image windows-2019 comes with VS2019 which by default uses the vc142 toolchain. Conda-forge moved to this toolchain only recently. It's possible to use vc142 also from VS2022, but less obvious, and easier to get wrong.
The reason the toolchain is an issue on windows in the first place is that static libraries (like npymath.lib)can only be consumed by toolchains at least as new as the one used to build it, so using vc143 (the default in VS2022) would force anyone depending on that to upgrade to VS2022. For example numpy inadvertently moved to vc142 by updating away from a deprecated image, leading to #20712 & #21346, etc.
There's also efforts (by @mattip mainly) to refactor npymath to be a header-only lib, which would alleviate this situation.
On macos, it's possible to build for older target with newer SDKs, but the older targets (10.x) aren't supported by the SDKs >12.0 anymore AFAIR.
On linux, I don't know the relation here between [ubuntu-22.04, manylinux_x86_64]. Manylinux is CentOS-based, and has the lowest-denominator ABI (=glibc version etc.) that makes sure the wheels are installable on machines with an OS newer than CentOS X (depending on the manylinux version). I don't see where ubuntu enters the equation here.
In any case (mainly @EwoutH), this is a topic with potentially pretty far-reaching implications w.r.t. how much of the user base remains supported. Yes it'd be nice to live at the head, but numpy tends to sit quite far down the stack, where things move much more slowly.
There was a problem hiding this comment.
Thanks for the detailed explanation. I will remove the runner image changes from this PR, and for some images we could maybe move in a separate PR. macOS 10.15 is deprecated and will be removed around December 1st (within a month).
To raise awareness of the upcoming removal, we will temporarily fail jobs using macOS 10.15. Builds that are scheduled to run during the brownout periods will fail.
There was a problem hiding this comment.
I think we have moved to the macos-11 image for testing in #22043. I don't know enough about macos to say how using this in the wheel build will affect users. Does it change the wheel tags (currently macosx_10_9_x86_64.whl and macosx_11_0_arm64.whl)?
There was a problem hiding this comment.
@h-vetinari Could we use MacOS 12 then? If 11 is going away we need a replacement.
There was a problem hiding this comment.
I think we have moved to the macos-11 image for testing in #22043.
We should try that for the wheels. I wasn't worried about 1.23.x because the last release should be out before 10.15 goes away, but 1.24.x will need a later version.
There was a problem hiding this comment.
@h-vetinari Could we use MacOS 12 then? If 11 is going away we need a replacement.
10.15 is deprecated, 11 is still fine.
Last time I looked at this information was here, the relevant support matrix for the targets is here.
Of note is that even though Apple EOLs older OS versions quite aggressively, AFAIU there's still substantial numbers of users on older versions. But I don't know the Apple world so well.
Conda-forge is still at 10.9 as a default target (over 5 years EOL!), which is partially just because no-one has started a discussion on this (I think I'll open an issue...), but illustrates the point about how long the tail of this support can be.
Main new feature is that is that cibuildwheel now uses the stable Python 3.11.0 release for building Python 3.11 wheels. Changelog: https://cibuildwheel.readthedocs.io/en/stable/changelog/#v2112 [wheel build]
bd9022f to
a58ffa4
Compare
|
I removed the image changes for now, so this PR is only bumping cibuildwheel. How can I test the wheel building? I added |
Needs the "Build" label. I think "Release" also works, but am not sure of that. |
|
Hmm, the pp38-win wheel segfaulted. ISTR seeing that before. |
|
I'll try restarting that build. Note that all the builds issue a warning: The warning is also in the nightly builds, so not specific to this update. The pypy win build also segfaulted in the last nightly build. EDIT: The warning comes from |
Would you like that included in this PR? |
No, but a new PR to try it out would be welcome. |
|
Going to put this in, the |
|
Thanks @EwoutH . |
|
Turns out that cibuildwheel 2.11.2 itself uses |
|
Thanks for merging! Since cibuildwheel 2.11 now supports cross-compiling Windows ARM64 wheels, I opened an issue for building those for NumPy: #22530 |
This PR updates cibuildwheel from 2.9.0 to 2.11.2 (changelog). This is mainly to use Python 3.11.0 (the stable release) in the CI instead of the 3.11.0rc1 release candidate 2.9.0 uses.
What's interesting, is that cibuildwheel now also supports cross-compiling Windows ARM64 wheels (see
CIBW_ARCHS).