PESQ
PESQ copied to clipboard
compatibility issue with compiled latest `pesq==0.0.4` and `numpy>=2.0`
Seems that the used imports were specific for numpy 1.x series and they are not valid for the upcoming 2.x which yields crashing...
import pesq as pesq_backend
File "/opt/hostedtoolcache/Python/3.9.19/x64/lib/python3.9/site-packages/pesq/__init__.py", line 5, in <module>
from ._pesq import pesq, pesq_batch
File "/opt/hostedtoolcache/Python/3.9.19/x64/lib/python3.9/site-packages/pesq/_pesq.py", line 8, in <module>
from .cypesq import cypesq, cypesq_retvals, cypesq_error_message as pesq_error_message
File "pesq/cypesq.pyx", line 1, in init cypesq
ImportError: numpy.core.multiarray failed to import (auto-generated because you didn't call 'numpy.import_array()' after cimporting numpy; use '<void>numpy._import_array' to disable if you are certain you don't need it).
Possible solutions:
- make the import compatible with
numpy2.x - restrict requirements to
numpy<2.0
thank you so much for raising this issue. it seems we should put the compatibility with numpy >2.0 on the schedule.
You probably don't have to do anything except remove the existing numpy<2 pin. For users everything presumably works fine already if they just install it with --no-build-isolation (and thus ignore that pin and get whichever NumPy is installed).
You need to build your wheels using numpy 2 (which offers backwards compatibility with numpy 1) instead of building them with numpy 1 (which does not provide forward compatibility with numpy 2)
Right, except I don't think pesq is uploading wheels, just sdists. So just doing a new without the pin is likely sufficient as a quick fix. (The requirements/setup could probably be improved to ask for NumPy >=2 to be used at build time, and of course wheels are great to have!)
Does that mean it is planned, or do I need to fork?
Hi @will-rice , you could folk it to use NumPy >=2 at building time as discussed above, and expose a wheel for users?