Is pin_compatible("numpy") still the recommended way of dealing with numpy after introduction of the new backwards compatiple C-API?

[maxnoe]

Your question:

Numpy 1.25 introduced a backwards compatible C-API with a definable minimum supported numpy version.

For a project defining -DNPY_TARGET_VERSION NPY_1_21_API_VERSION one could thus I think do:

requirements:
    build:
        - numpy >=1.25 # 1.25 needed for backwards-compatible C-API
    host:
        - numpy >=1.25 # 1.25 needed for backwards-compatible C-API
    run:
        - numpy >=1.21 # But result will be compatible with all version larger than NPY_TARGET_VERSION

Given this new mechanism, is {{ pin_compatible("numpy") }} still the way to go?

If not, we should update the knowledge base section on numpy.

[hmaarrfk]

I think for now we are still using the "old way".

Note that conda-forge today targets numpy 1.22+

The discussions: https://github.com/conda-forge/conda-forge.github.io/issues/1997 https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/4816

are helpful to build context

[h-vetinari]

Yeah, pin_compatible is not really ideal for numpy, unless one uses explicit arguments for lower & upper bounds. The lower bound corresponds to NPY_TARGET_VERSION, and the upper bound generally corresponds to 1.{N+3}. I think the latter scheme will continue also after numpy 2.0

[carterbox]

I thought that the numpy feedstock defines its own run_exports now, so downstream recipes needn't do any pinning. i.e. It's the numpy feedstock maintainers who are responsible for pinnings.

[h-vetinari]

Yes, we'll actually remove the pin_compatible("numpy") usage in the context of #1997.

[jakirkham]

Looking at using a piggyback migrator to start making this change: https://github.com/regro/cf-scripts/issues/2469

Though maintainers are welcome to start working on this sooner 🙂

[jakirkham]

Also we are planning to drop this from the docs

xref: https://github.com/conda-forge/conda-forge.github.io/issues/2156