Installing matplotlib dependency locks xcdat version to 0.6.0 due to `numba`/`llvmlite` lack of Python 3.14 support

[durack1]

Hi folks, I hope all is well that side.

I've just started to recreate a number of miniforge environments and tripped over this one:

(base) airy2:~ paully$ mamba create --dry-run -n xcd0101 -c conda-forge xcdat
conda-forge/noarch                                          Using cache
conda-forge/osx-arm64                                       Using cache

Transaction
  Prefix: /Users/paully/miniforge3/envs/xcd0101
  Updating specs:

   - xcdat

  Package                                  Version  Build                    Channel           Size
  Install:

  + aws-c-auth                               0.9.1  h753d554_5               conda-forge      107kB
...
  + numpy                                    2.3.4  py313h9771d21_0          conda-forge        7MB
...
  + python                                  3.13.9  hfc2f54d_101_cp313       conda-forge       12MB
...
  + xarray                               2025.10.1  pyhcf101f3_1             conda-forge      981kB
  + xcdat                                   0.10.1  pyhd8ed1ab_0             conda-forge       76kB
  + xesmf                                   0.8.10  pyhd8ed1ab_0             conda-forge       46kB
...

Whereas, if I add matplotlib I get:

(base) airy2:~ paully$ mamba create --dry-run -n xcd0101 -c conda-forge xcdat matplotlib
conda-forge/noarch                                          Using cache
conda-forge/osx-arm64                                       Using cache

Transaction

  Prefix: /Users/paully/miniforge3/envs/xcd0101

  Updating specs:

   - xcdat
   - matplotlib

  Package                                  Version  Build                    Channel           Size
  Install:

  + aws-c-auth                               0.9.1  h753d554_5               conda-forge      107kB
...
  + matplotlib                              3.10.7  py314he55896b_0          conda-forge       18kB
...
  + numpy                                    2.3.4  py314h5b5928d_0          conda-forge        7MB
...
  + python                                  3.14.0  h40d2674_102_cp314       conda-forge       14MB
...
  + xarray                               2025.10.1  pyhcf101f3_1             conda-forge      981kB
  + xcdat                                    0.6.0  pyhd8ed1ab_0             conda-forge       72kB
  + xgcm                                     0.9.0  pyhd8ed1ab_0             conda-forge        3MB
...

Is this expected? Is there some pinned libraries somewhere causing my issue?

[durack1]

@tomvothecoder this might be related to #808

[tomvothecoder]

Hi @durack1, thank you for reporting this. #808 is actually misleading and should be updated, since the xcdat recipe for the latest versions supports Python ≥3.11 with noarch.

I re-ran your commands and noticed esmpy / xesmf is not included with xcdat=0.6.0. Taking a diff of the console outputs revealed the root cause: numba/llvmlite (used by xesmf) has incomplete support for Python 3.14 on conda-forge. As a result, the conda solver falls back to the most compatible packages, including an older version of xcdat without xesmf (and numba/llvmlite).

Workaround

Pin Python 3.13 (or python<3.14) directly. We'll keep this GitHub issue open until it is resolved and keep track of progress on the numba/llvmlite side.

conda create -n xcd0101 -c conda-forge python=3.13 xcdat matplotlib

More Context

• Adding matplotlib makes the solver prioritize Python 3.14, since that’s the version it has current builds for.
• xcdat 0.10.1 depends on xesmf ≥ 0.8.7, which depends on esmpy ≥ 8.6, numba, and llvmlite.
• The latest esmpy builds are compatible with Python 3.14.
• xesmf sub-dependencies numba / llvmlite are not yet fully migrated on conda-forge.
  • Python 3.14 numba/numba#9957
  • llvmlite CI support for Python 3.14 numba/llvmlite#1281
  • Because of that, the solver can’t satisfy all dependencies and falls back to xcdat 0.6.0, which doesn’t require xesmf (xesmf was optional until v0.7.0).

[tomvothecoder]

Notes

Simulation solving for Python 3.14 vs. 3.13

# Python 3.14 solve (works, but picks up xcdat=0.6.0 without xesmf/esmpy/numba)
conda create --dry-run -n test314 -c conda-forge python=3.14 xcdat matplotlib

# Python 3.13 solve (works, picks up xcdat=0.10.1 with xesmf/esmpy/numba)
conda create --dry-run -n test313 -c conda-forge python=3.13 xcdat matplotlib

Try installing ESMPy directly under 3.14

Result: SUCCESS with latest version of esmpy=8.9.0 and python=3.14.0

conda create -n esmpy314 -c conda-forge python=3.14 esmpy --dry-run

Try numba directly with 3.14

Result: FAILS, no Python 3.14 support yet. The upcoming release of numba=0.63.0 should support 3.14 (link).

• Python 3.14 numba/numba#9957
• llvmlite CI support for Python 3.14 numba/llvmlite#1281

conda create --dry-run -n test-numba314 -c conda-forge python=3.14 numba

(esmpy314) vo13@ml-5556678 ~ % conda create --dry-run -n test-numba314 -c conda-forge python=3.14 numba
/opt/miniconda3/lib/python3.12/site-packages/conda/base/context.py:211: FutureWarning: Adding 'defaults' to channel list implicitly is deprecated and will be removed in 25.9. 

To remove this warning, please choose a default channel explicitly with conda's regular configuration system, e.g. by adding 'defaults' to the list of channels:

  conda config --add channels defaults

For more information see https://docs.conda.io/projects/conda/en/stable/user-guide/configuration/use-condarc.html

  deprecated.topic(
Channels:
 - conda-forge
 - defaults
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - nothing provides _python_rc needed by python-3.14.0rc1-h6ea10a9_2_cp314t

Could not solve for environment specs
The following packages are incompatible
├─ numba =* * is installable with the potential options
│  ├─ numba [0.52.0|0.53.0|...|0.58.1] would require
│  │  └─ python >=3.8,<3.9.0a0 *, which can be installed;
│  ├─ numba [0.55.0|0.55.1|...|0.62.1] would require
│  │  └─ python >=3.10,<3.11.0a0 *, which can be installed;
│  ├─ numba [0.53.0|0.53.1|...|0.60.0] would require
│  │  └─ python >=3.9,<3.10.0a0 *, which can be installed;
│  ├─ numba [0.57.0|0.57.1|...|0.62.1] would require
│  │  └─ python >=3.11,<3.12.0a0 *, which can be installed;
│  ├─ numba [0.59.0|0.59.1|...|0.62.1] would require
│  │  └─ python_abi =3.12 *_cp312, which requires
│  │     └─ python =3.12 *_cpython, which can be installed;
│  ├─ numba [0.61.0|0.61.2|0.62.0|0.62.1] would require
│  │  └─ python_abi =3.13 *_cp313 with the potential options
│  │     ├─ python_abi 3.13 would require
│  │     │  └─ python =3.13 *_cpython, which can be installed;
│  │     └─ python_abi 3.13 would require
│  │        └─ python =3.13 *_cp313, which can be installed;
│  └─ numba [0.59.0|0.59.1|...|0.62.1] would require
│     └─ python >=3.12,<3.13.0a0 *, which can be installed;
└─ python =3.14 * is not installable because there are no viable options
   ├─ python 3.14.0 conflicts with any installable versions previously reported;
   └─ python [3.14.0rc1|3.14.0rc2|3.14.0rc3] would require
      └─ _python_rc =* *, which does not exist (perhaps a missing channel).

[durack1]

3.13 will do for the moment, I had assumed it was something trivial, so glad you've managed to diagnose the issue, which might just magically solve itself in the coming weeks