`numba=0.61.2` build 0 still a valid alternative, can result in `ImportError: Numba needs NumPy 2.2 or less. Got NumPy 2.3.`

[tomvothecoder]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Hello, I think numba=0.61.2 build 0 needs to be marked as unavailable to prevent users from being able to download it. Otherwise, the conda solver can pick it up as a valid alternative which can result in ImportError: Numba needs NumPy 2.2 or less. Got NumPy 2.3. if the latest numpy>2.3 is also picked up.

More Context

In my comment, I noted that the issue appears to stem from build 0 of numba=0.61.2 not enforcing a numpy <2.3 constraint, which led to compatibility problems. A patch was introduced in build 1 of numba=0.61.2, which properly prevents it from being installed with numpy >=2.3.

Now, @jypeter is running into trouble when using conda update --all, which attempts to:

* upgrade `numpy` from 2.2.6 to 2.3.1,

* remove `numba`, `xesmf`, etc.,

* and downgrade `xcdat`, `xskillscore`, and other packages.

This seems to be the conda solver aggressively trying to update all packages, ignoring the compatibility boundaries unless they're explicitly pinned. When he runs conda update --all 'numpy<2.3', everything resolves cleanly.
Source: xCDAT/xcdat#775 (comment)

Someone probably needs to make a PR to conda-forge/admin-requests to fix the version constrain in build 0. Otherwise, that build will still remain a valid alternative. build 1 gets favored over build 0 but that doesn't mean the solver won't fall back on build 0 if it helps solve the whole matrix of dependencies.
Source: xCDAT/xcdat#775 (comment)

Installed packages

numpy>2.3
numba=0.61.2 (build 0)

Environment info

numpy>2.3
numba=0.61.2 (build 0)

[xylar]

@tomvothecoder, it looks like this has already been fixed conda-forge/conda-forge-repodata-patches-feedstock#1039.

When I search for this version, I see the fix:

$ conda search --info numba=0.61.2
Loading channels: done
numba 0.61.2 py310h699fe88_0
----------------------------
file name   : numba-0.61.2-py310h699fe88_0.conda
name        : numba
version     : 0.61.2
build       : py310h699fe88_0
build number: 0
size        : 4.2 MB
license     : BSD-2-Clause
subdir      : linux-64
url         : https://conda.anaconda.org/conda-forge/linux-64/numba-0.61.2-py310h699fe88_0.conda
md5         : 824facdcc7be56254cbc63fa28cb06aa
timestamp   : 2025-04-09 20:57:59 UTC
constraints : 
  - cuda-python >=11.6
  - cuda-version >=11.2
  - cudatoolkit >=11.2
  - libopenblas !=0.3.6
  - tbb >=2021.6.0
  - scipy >=1.0
dependencies: 
  - __glibc >=2.17,<3.0.a0
  - _openmp_mutex >=4.5
  - libgcc >=13
  - libstdcxx >=13
  - llvmlite >=0.44.0,<0.45.0a0
  - numpy >=1.19,<3
  - numpy >=1.24,<2.3.0a0
  - python >=3.10,<3.11.0a0
  - python_abi 3.10.* *_cp310

...

So I think your user (@jypeter) may have installed the package before the patch went in to fix it or may be using a cached version without the fix. In any case, I don't think there's anything further than the maintainers here can do to address this that hasn't already been done. I think this is partly why it is better to use conda create than conda update, though I don't know how that handles cached packages that have later been patched.

[tomvothecoder]

@xylar thank you for the additional investigation. I will close this issue based on your findings and direct @jypter to try cleaning out cache packages before re-creating a new environment.