Open maxnoe opened 11 months ago
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
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
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.
Yes, we'll actually remove the pin_compatible("numpy")
usage in the context of #1997.
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 🙂
Also we are planning to drop this from the docs
xref: https://github.com/conda-forge/conda-forge.github.io/issues/2156
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:Given this new mechanism, is
{{ pin_compatible("numpy") }}
still the way to go?If not, we should update the knowledge base section on numpy.