NumPy 2 bringup
jakirkham opened this issue ยท 66 comments
NumPy is currently working on a NumPy 2.0 release, which is planned to come out later this year. Here are the current (draft) release notes. Also here's the upstream tracking issue ( numpy/numpy#24300 )
Some questions worth discussing:
- How do we handle tightening loose
numpy
pins in packages ( conda-forge/conda-forge-repodata-patches-feedstock#516 )? - Do we want to keep building for NumPy 1 & 2 at the same time?
- What timeline do we want to use for adding NumPy 2?
- What timeline do we want to use for dropping NumPy 1?
- How should this be coordinated around other major migrations (like Python 3.12 or a new Boost)?
- Numpy now builds for the "oldest-available-C-API" by default, i.e. we could build for our current 1.22 C-API using numpy 1.25; we need to adapt to this in any case, at the latest when our lower bound becomes 1.25 (see conda-forge/conda-forge-pinning-feedstock#4816)?
- Anything else we should discuss?
cc @conda-forge/core
Can we merge these two issues just to make it easier to track them?
The issue Axel raises seems like a subpoint of this issue (depending on what we decide). Namely do we want to opt-in to this newer/slimmer ABI and how does that fit into NumPy 2
Sure. IMO Axel issue is a subset of this one. I don't have strong opinions on which one to keep, or if you want to keep both, but I also don't want to get lost on two mega-threads ๐ฌ
Added Axel's item to the list above
Handling the ABI is the key point here (that and current packages missing a <2
). I updated the added item because the summary was not accurate.
Normally I'd say we do a dual migration (keep 1.x; add 2.0), but numpy has around 5000** dependents in conda-forge, so that would be a pretty substantial CI impact, especially if it takes a while to drop 1.x.
**
>mamba repoquery whoneeds numpy -c conda-forge -p linux-64 > tmp
># edit to remove header
>python
>>> q = open("tmp", "r").readlines()
>>> p = {x.strip().split(" ")[0] for x in q} - {""}
>>> len(p)
4898
Obviously not all of them are compiling against numpy, but still...
I updated the added item because the summary was not accurate.
Thanks Axel! ๐
Anyone should feel free to update the issue as needed ๐
Following up on our discussion earlier about improving the visibility of NPY_FEATURE_VERSION
, started this NumPy PR ( numpy/numpy#24861 ) to message how the value is set
Also include a note about one approach we might take to ensure that value is embedded in built binaries. Though maybe there are better approaches for that portion