Build fails with NumPy 2.x

[penguinpee]

With NumPy 2.2.0 the following error occurs. Fedora intents to ship NumPy 2.x with the next release (Fedora 42) and would like to drop NumPy 1.x from that release.

gradunwarp/core/interp3_ext.c: In function ‘interp3’:
gradunwarp/core/interp3_ext.c:93:31: error: lvalue required as left operand of assignment
   93 |         PyArray_FLAGS(result) |= NPY_OWNDATA;
      |                               ^~
gradunwarp/core/interp3_ext.c:97:51: warning: passing argument 1 of ‘(PyObject * (*)(PyObject *))*(PyArray_API + 784)’ from incompatible pointer type [-Wincompatible-pointer-types]
   97 |     itr_v = (PyArrayIterObject *) PyArray_IterNew(result);
      |                                                   ^~~~~~
      |                                                   |
      |                                                   PyArrayObject * {aka struct tagPyArrayObject_fields *}
gradunwarp/core/interp3_ext.c:97:51: note: expected ‘PyObject *’ {aka ‘struct _object *’} but argument is of type ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’}
gradunwarp/core/interp3_ext.c:98:51: warning: passing argument 1 of ‘(PyObject * (*)(PyObject *))*(PyArray_API + 784)’ from incompatible pointer type [-Wincompatible-pointer-types]
   98 |     itr_r = (PyArrayIterObject *) PyArray_IterNew(R);
      |                                                   ^
      |                                                   |
      |                                                   PyArrayObject * {aka struct tagPyArrayObject_fields *}
gradunwarp/core/interp3_ext.c:98:51: note: expected ‘PyObject *’ {aka ‘struct _object *’} but argument is of type ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’}
gradunwarp/core/interp3_ext.c:99:51: warning: passing argument 1 of ‘(PyObject * (*)(PyObject *))*(PyArray_API + 784)’ from incompatible pointer type [-Wincompatible-pointer-types]
   99 |     itr_c = (PyArrayIterObject *) PyArray_IterNew(C);
      |                                                   ^
      |                                                   |
      |                                                   PyArrayObject * {aka struct tagPyArrayObject_fields *}
gradunwarp/core/interp3_ext.c:99:51: note: expected ‘PyObject *’ {aka ‘struct _object *’} but argument is of type ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’}
gradunwarp/core/interp3_ext.c:100:51: warning: passing argument 1 of ‘(PyObject * (*)(PyObject *))*(PyArray_API + 784)’ from incompatible pointer type [-Wincompatible-pointer-types]
  100 |     itr_s = (PyArrayIterObject *) PyArray_IterNew(S);
      |                                                   ^
      |                                                   |
      |                                                   PyArrayObject * {aka struct tagPyArrayObject_fields *}
gradunwarp/core/interp3_ext.c:100:51: note: expected ‘PyObject *’ {aka ‘struct _object *’} but argument is of type ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’}
gradunwarp/core/interp3_ext.c:123:16: warning: returning ‘PyArrayObject *’ {aka ‘struct tagPyArrayObject_fields *’} from a function with incompatible return type ‘PyObject *’ {aka ‘struct _object *’} [-Wincompatible-pointer-types]
  123 |         return result;
      |                ^~~~~~
error: command '/usr/bin/gcc' failed with exit code 1

[effigies]

Should be fixed by #9, but there hasn't been a tag since then.

[penguinpee]

Thanks. I'll try that as a patch.

[penguinpee]

I'm not sure I feel comfortable carrying that as a patch downstream. I don't mean the PR as a patch. That applies cleanly. But the implications on the build and the package are such that I'd rather wait for the next release. Are there any plans?

Meanwhile, I check with my co-maintainers what they think.

[glasserm]

As far as I am concerned a release would be fine. What does @coalsont think?

[coalsont]

I have no specific objections. @effigies would it be good to merge #17 first?

[effigies]

Yes, I think so.

[coalsont]

@effigies you said this, which suggests something might get angry if pypi is still holding the name:

#17 (comment)

What would the effects be?

[effigies]

The effects would be another failure to upload to pypi, but that's not the end of the world. If it makes life easier for Fedora to have a tag to rely on, we shouldn't wait on PyPI.

[coalsont]

I merged #17, and made a new release and tag.

[penguinpee]

Thanks! Much appreciated. Automation already picked up on the new tag. I'll take care of updating the package in Fedora. Hopefully, you will get hold of the PyPI name soon.