PR #730 introduced a pyproject.toml that declares build dependencies - this means that a pip install chaco will automatically first install NumPy, instead of just failing because NumPy isn't present in the build environment.
But there's a subtle problem here: with the current pyproject.toml,
pip install chaco will build Chaco against the latest release of NumPy available from PyPI (regardless of any version of NumPy that happens to already be in the environment)- the extension modules generated this way will not necessarily be compatible with earlier versions of NumPy
The result is that the built Chaco may segfault if installed into an environment whose NumPy version is not the latest NumPy.
As a general rule, extension modules built against earlier versions of NumPy can reasonably be expected to be ABI-compatible with later versions of NumPy, but not the other way around.
A possible solution is to pin the NumPy version (just to the minor version, not the bugfix level) used for the build to the earliest NumPy version that we might want to support. This is the approach taken in ibm2ieee, for example.
See also previous discussion in #467.
xref: enthought/ibm2ieee#7, enthought/ibm2ieee#8, enthought/ibm2ieee#9, enthought/ibm2ieee#10
further reading: pypa/pip#6144, pypa/pip#4582, numpy/numpy#5888
PR #730 introduced a
pyproject.tomlthat declares build dependencies - this means that apip install chacowill automatically first install NumPy, instead of just failing because NumPy isn't present in the build environment.But there's a subtle problem here: with the current
pyproject.toml,pip install chacowill build Chaco against the latest release of NumPy available from PyPI (regardless of any version of NumPy that happens to already be in the environment)The result is that the built Chaco may segfault if installed into an environment whose NumPy version is not the latest NumPy.
As a general rule, extension modules built against earlier versions of NumPy can reasonably be expected to be ABI-compatible with later versions of NumPy, but not the other way around.
A possible solution is to pin the NumPy version (just to the minor version, not the bugfix level) used for the build to the earliest NumPy version that we might want to support. This is the approach taken in
ibm2ieee, for example.See also previous discussion in #467.
xref: enthought/ibm2ieee#7, enthought/ibm2ieee#8, enthought/ibm2ieee#9, enthought/ibm2ieee#10
further reading: pypa/pip#6144, pypa/pip#4582, numpy/numpy#5888