conda-forge/conda-forge.github.io

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