DOC: add guide for downstream package authors#18505
Conversation
|
|
||
| If a package either uses the NumPy C API directly or it uses some other tool | ||
| that depends on it like Cython or Pythran, NumPy is a *build-time* dependency | ||
| of the package. Because the NumPy ABI is only forward-compatible, you must |
There was a problem hiding this comment.
It is backwards-campatible. It would be a good idea to explain what these terms mean, i.e., C extensions compiled against older NumPy will run on newer NumPy, but not the other way around. This conflicts a bit with the ABI, which may change due to deprecated and removed functions. We do try to insure that there are workarounds in older NumPy for such problems.
There was a problem hiding this comment.
I had to look it up, but I'm pretty sure I remembered correctly. It's counter-intuitive, because the meaning usage is opposite for API vs. ABI. From https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html:
Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.
There was a problem hiding this comment.
Ah I did get it wrong higher up.
|
Thanks Ralf. |
This is a follow-up to the approach to specifying versions of numpy to depend on worked out in scipy/scipy#12862. And it adds a bit about testing against NumPy nightlies.