[Bug]: conda solver picks numpy-2-incompatible regionmask 0.4.0 alongside xcdat in some envs

[will-s-hart]

What happened?

When creating a conda environment containing xcdat alongside certain other dependencies (I hit it with geoviews), the (libmamba) solver picks an old version of regionmask (0.4.0). That version isn't compatible with numpy 2 — it uses the now-removed np.NaN — so import xcdat fails with an AttributeError (full traceback in the log section below).

The trap doesn't appear with conda create -c conda-forge xcdat alone — it only triggers when xcdat is combined with certain other packages. Forcing regionmask>=0.11 on the install command line resolves cleanly, so the solver has no trouble finding a numpy-2-compatible regionmask when asked (it just for some reason doesn't pick one by default).

What did you expect to happen? Are there are possible answers you came across?

While this isn't strictly an xcdat issue, I wonder whether it would be worth pinning regionmask >=0.11 (this appears to be the first numpy 2 compatible release - regionmask/regionmask#440) here.

Minimal Complete Verifiable Example (MVCE)

conda create -n xcdat_test -c conda-forge xcdat geoviews
conda activate xcdat_test
python -c "import xcdat"

Relevant log output

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import xcdat
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/xcdat/__init__.py", line 25, in <module>
    from xcdat.spatial import SpatialAccessor  # noqa: F401
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/xcdat/spatial.py", line 18, in <module>
    from xcdat.mask import (
    ...<2 lines>...
    )
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/xcdat/mask.py", line 4, in <module>
    import regionmask
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/regionmask/__init__.py", line 15, in <module>
    from .core.regions import Regions_cls, Region_cls
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/regionmask/core/regions.py", line 17, in <module>
    from .mask import _mask
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/regionmask/core/mask.py", line 214, in <module>
    def create_mask_contains(lon, lat, coords, fill=np.NaN, numbers=None):
                                                    ^^^^^^
  File "/opt/homebrew/Caskroom/miniforge/base/envs/xcdat_test/lib/python3.14/site-packages/numpy/__init__.py", line 778, in __getattr__
    raise AttributeError(
    ...<3 lines>...
    )
AttributeError: `np.NaN` was removed in the NumPy 2.0 release. Use `np.nan` instead.

Anything else we need to know?

As an aside, mamba (standalone) consistently picks regionmask 0.13.0 in the same install command — only conda (with libmamba solver) falls into the trap.

Environment

xcdat 0.11.2

INSTALLED VERSIONS

commit: None
python: 3.14.5 | packaged by conda-forge | (main, May 20 2026, 00:45:47) [Clang 20.1.8 ]
python-bits: 64
OS: Darwin
OS-release: 25.3.0
machine: arm64
processor: arm
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.14.6
libnetcdf: 4.10.0

xarray: 2026.4.0
pandas: 3.0.3
numpy: 2.4.6
scipy: 1.17.1
netCDF4: 1.7.4
pydap: None
h5netcdf: None
h5py: None
zarr: None
cftime: 1.6.5
nc_time_axis: None
iris: None
bottleneck: None
dask: 2026.3.0
distributed: 2026.3.0
matplotlib: 3.10.9
cartopy: 0.25.0
seaborn: None
numbagg: None
fsspec: 2026.4.0
cupy: None
pint: None
sparse: 0.18.0
flox: None
numpy_groupies: None
setuptools: 82.0.1
pip: 26.1.1
conda: None
pytest: None
mypy: None
IPython: None
sphinx: None

[will-s-hart]

Having done some investigations myself and with AI agent assistance to try understand the issue, I'm still not fully sure of the root cause, but in case useful here's an agent-generated summary of our best understanding:

"Recent regionmask requires rasterio, and rasterio 1.5.0 is hard-pinned against libgdal-core <3.13 and proj <9.8 — while other parts of the solve (e.g. geoviews via cartopy) pull in the latest libgdal 3.13 / proj 9.8. cartopy's conda metadata doesn't currently declare an upper bound on proj, but the latest cartopy is in fact broken with proj 9.8 in practice (the missing upper bound is being added in SciTools/cartopy#2653) — so the "latest-of-everything" solve is already a degenerate state regardless of regionmask. With regionmask only transitive (xcdat doesn't pin it), the libmamba solver finds an apparently-cheap solve where regionmask is downgraded all the way back to 0.4.0 (the only build with no rasterio dep), avoiding rasterio's libgdal/proj caps — and that's what we hit on import xcdat. The exact mechanism for why this beats "add rasterio + downgrade libgdal/proj" isn't fully nailed down: the result varies with --repodata-fn choice (repodata.json vs current_repodata.json) and conda's cache state, and mamba (standalone) consistently picks the right path on the same command. Either pinning regionmask >=0.11 in xcdat, or the upstream cartopy proj upper bound landing in conda-forge, would close the trap."

[tomvothecoder]

Thank you @will-s-hart for reporting this!

I will try to reproduce this my end and see if pinning regionmask>=0.11. is the way to go for NumPy >=2.0 support.

[tomvothecoder]

I've updated the regionmask constraint to >=0.11.0 in #838 and added the v0.11.2 conda-forge patch here, which ensures compatibility with numpy >=2.0 (an xCDAT requirement).

I also opened regionmask/regionmask#657 for the regionmask maintainers to consider adding a patch that constrains older versions of regionmask on conda-forge to numpy 1.0 only.