-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLD: build with numpy instead of oldest-supported-numpy #478
BLD: build with numpy instead of oldest-supported-numpy #478
Conversation
I also updated the minimal requirement for numpy to sync it with |
6d5a94e
to
49b8e33
Compare
Your suggestion sounds good to me. However, there are still some issues in building the wheels in CI:
|
Oh, I didn't see this when I tested locally, but luckilly I already had to deal with this exact change in a different package downstream of NumPy ! I should be able to fix this quickly. |
I was able to reproduce the crash locally when I switched from Python 3.12 to 3.9, and I just pushed a fix. |
LGTM. Thanks @neutrinoceros ! |
This was included in numexpr 2.10, right? However I see an import failure of numexpr claiming it wasn't compiled against numpy 2.0 here: Any idea? Or am I misreadig this and it's not actually numexpr? |
It was indeed included in 2.10
so I think a different dependency may be adding constraints which prevent 2.10 from being installed. I would recommend running |
Thanks! I saw 2.10 but that was only in the isolated wheel build environment, indeed in the actual runtime environment, the old version was installed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Clément and Francesc! 🙏
It is nice to see the NumPy 2 upgrade in numexpr was relatively straightforward 🥳
Have noted a couple things we might be able to smooth out, which should also make maintenance easier going forward
cc @seberg (for awareness)
def_macros = [ | ||
# keep in sync with minimal runtime requirement (requirements.txt) | ||
('NPY_TARGET_VERSION', 'NPY_1_19_API_VERSION') | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AIUI this shouldn't be needed unless numexpr is doing something more particular with the NumPy API
During the conda-forge NumPy 2 bringup discussion we talked to @rgommers about this, Ralf wrote up a nice explanation here ( conda-forge/conda-forge.github.io#1997 (comment) ). Quoting that below:
- numpy's
pyproject.toml
contains and enforces the lowest-supported version, e.g.:requires-python = ">=3.9"
- the first numpy version to support that python version (e.g.,
1.19.0
for py39) determined the maximum version thatNPY_FEATURE_VERSION
may be set to- when that
>=3.9
is bumped to>=3.10
, then that max-allowed version forNPY_FEATURE_VERSION
moves up.
So would suggest dropping
def_macros = [ | |
# keep in sync with minimal runtime requirement (requirements.txt) | |
('NPY_TARGET_VERSION', 'NPY_1_19_API_VERSION') | |
] | |
def_macros = [] |
@@ -1 +1 @@ | |||
numpy >= 1.13.3 | |||
numpy >= 1.19.3 # keep in sync with NPY_TARGET_VERSION (setup.py) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly the version constraint here could be dropped if we just want to support the oldest NumPy available on Python 3.9. Unless of course there are other reasons than NumPy C API to set a NumPy minimum
numpy >= 1.19.3 # keep in sync with NPY_TARGET_VERSION (setup.py) | |
numpy |
/* Get the sizes of all the operands */ | ||
dtypes_tmp = NpyIter_GetDescrArray(iter); | ||
for (i = 0; i < n_inputs+1; ++i) { | ||
self->memsizes[i] = dtypes_tmp[i]->elsize; | ||
self->memsizes[i] = PyDataType_ELSIZE(dtypes_tmp[i]); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if it is possible to rewrite this with PyArray_ITEMSIZE
as that works on NumPy 1 & 2 based on this release note
@@ -1203,7 +1203,7 @@ NumExpr_run(NumExprObject *self, PyObject *args, PyObject *kwds) | |||
Py_INCREF(dtypes[0]); | |||
} else { // constant, like in '"foo"' | |||
dtypes[0] = PyArray_DescrNewFromType(NPY_STRING); | |||
dtypes[0]->elsize = (int)self->memsizes[1]; | |||
PyDataType_SET_ELSIZE(dtypes[0], (npy_intp)self->memsizes[1]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if there is a way to write this so it branches on NPY_ABI_VERSION
. That way there could be NumPy 1 & 2 compilation paths
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The easiest way is to define the macro if it isn't defined. Without that users can't do a local build with build isolation on old NumPy (which won't allow to compile with numpy 1 and run in 2, that would be harder).
Clearer instructions: https://numpy.org/devdocs/numpy_2_0_migration_guide.html#the-pyarray-descr-struct-has-been-changed
I noticed while testing a downstream package that the following
ImportError
was raised from NumPy 2.0.0rc1 pointing to numexpr:Traceback
For more context:
oldest-supported-numpy
is superseded by NumPy itself since version 1.25.0It is recommended by NumPy developers to plan releases of packages with Python extensions a some point between 2.0.0rc1 and 2.0.0 (final), which from the looks of it should be a couple months from now.