bindings/python: use Numpy 2.x; update wheel builds#20
Merged
arahlin merged 4 commits intoketiltrout:masterfrom Dec 17, 2025
Merged
bindings/python: use Numpy 2.x; update wheel builds#20arahlin merged 4 commits intoketiltrout:masterfrom
arahlin merged 4 commits intoketiltrout:masterfrom
Conversation
Because Numpy 2.x shared libraries are ABI compatible back to Numpy 1.x, this requires a newer build environment to produce the Python bindings, but the resulting library is backwards compatible. (This is ideal for a wheel-based flow.)
Contributor
Author
|
@ketiltrout and @arahlin, sorry to drop this on you before the holidays. This is a precursor to #21. |
arahlin
approved these changes
Dec 17, 2025
Collaborator
|
I think the footprint of this PR is relatively small and otherwise simplifies python wheels and forward compatibility a great deal. |
arahlin
pushed a commit
that referenced
this pull request
Feb 6, 2026
…Windows wheels (#21) This PR builds on the previous one (#20), so while it's a big change, it's not as sprawling as it seems. My primary motivation is getting Windows wheels built for pygetdata. This created a fair cascade of tasks because: - autotools only works on UNIX-like environments (including MSYS2/cygwin), but - on Windows, native Python .pyd modules are really only supported using MSVC - If we do that, the MacOS and Linux wheel builders should come along for the ride. Practically speaking, native Windows support needs CMake instead of autotools, and switching the MacOS/Linux wheel builders at the same time makes sense. The autotools flow remains in place (and the github regression tests still pass against it.) This PR contains a mix of "omnibus commits" (an incremental modernization of the CMake infrastructure does not make sense) and "drive-by commits" for individual bug fixes or improvements. Note that we have definitely left Python 2.x behind (Numpy 2.x never supported it anyways).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR shifts the Python bindings from the Numpy 1.x to Numpy 2.x API. See the following for context:
https://numpy.org/doc/stable/numpy_2_0_migration_guide.html
https://numpy.org/doc/2.0/dev/depending_on_numpy.html
Numpy 2.x is now a better choice than 1.x for modules:
It makes sense to shift getdata in the same direction too. Along the way, I've refreshed the wheel build (to repair deprecated MacOS builders, to enable Python 3.13, and to deprecate 3.8.)
Comments welcome. While the build succeeds and regression tests pass, I have not used these code "in anger". I do plan to follow up this PR with a wheel builder for Windows, and think Numpy 2.x is a better basis for this work.