MIT-LCP
Bump dependencies for NumPy 2 compatibility
All tests pass and demo.ipynb works without any errors or warnings using NumPy >= 2.
OK, I'm struggling a bit with dependencies here. If you want to keep Python >= 3.9 and at the same time also support 3.13, scipy >= 1.13.1 works only for Python <= 3.12. Strangely, uv does not use scipy 1.14.1 (there is no binary wheel for scipy 1.13.1 for Python 3.13) for Python 3.13, but insists on using 1.13.1...
Sure, seems like the problem is that "uv run --extra dev pytest" is doing something bizarre.
I don't know exactly what that command is doing or trying to do, but it seems to be trying to install the oldest versions of packages that satisfy our dependencies. That is not what we want (that's not what any normal user does) and is not likely to lead to a good solution.
It might actually be something at the core of how uv resolves dependencies, yes. I've opened an issue here: https://github.com/astral-sh/uv/issues/8492
Hmmm, the Windows 3.13 job crashed, but this might be unrelated. @bemoody or @tompollard could you please restart this job (I don't have the permissions to do that myself)?
We're hitting another issue, this time related to CPython (https://github.com/python/cpython/issues/125235). We gotta wait for 3.13.1 for the fix.
This is ready for review. Everything works with NumPy >= 2. I've removed support for Python 3.8 and added Python 3.12. Python 3.13 can be added as soon as 3.13.1 is released, but I would do that in a separate PR. It would be great if you could push out a new release to PyPI once this PR gets merged.
Note that we could also force specific NumPy versions for each Python version as shown e.g. here (they are testing the oldest supported NumPy version for each Python release).
The NumPy >= 2 requirement is currently only necessary for the test, because otherwise these would use 1.26.4.
WDYT?
I appreciate your efforts to try to get to the bottom of these issues!
However, I don't think wfdb package should require numpy 2 at this stage, and I'm not inclined to change that just to appease uv.
Furthermore, before removing the "numpy < 2" requirement from pyproject.toml, I would like to see that the test suite is able to run on numpy 2, with NPY_PROMOTION_STATE set to "weak_and_warn", and with no warnings generated. Currently that's not the case.
That aside, we really need to have a CI workflow that tests whether the package can be installed using pip. If uv doesn't install exactly the same packages that pip would have installed, then uv is not an effective substitute.
However, I don't think wfdb package should require numpy 2 at this stage, and I'm not inclined to change that just to appease uv.
Of course, that's why I suggested to pin several NumPy versions (e.g., the oldest supported NumPy version per Python version).
Furthermore, before removing the "numpy < 2" requirement from pyproject.toml, I would like to see that the test suite is able to run on numpy 2, with NPY_PROMOTION_STATE set to "weak_and_warn", and with no warnings generated. Currently that's not the case.
Sure, I can do that!
That aside, we really need to have a CI workflow that tests whether the package can be installed using pip. If uv doesn't install exactly the same packages that pip would have installed, then uv is not an effective substitute.
Yes, we can use the uv pip interface instead, which behaves identically to pip. Although Astral devs are currently working hard to implement a resolver option to uv run/sync, which also behaves like pip, but I don't know how long it will take them. We can immediately switch to uv pip though.
If you are completely unhappy with uv, I can also get rid of it again and replace it with pip, just let me know.
Thanks!
Of course, that's why I suggested to pin several NumPy versions (e.g., the oldest supported NumPy version per Python version).
Yeah, that seems like a reasonable workaround as long as it's not too much work.
Yes, we can use the uv pip interface instead, which behaves identically to pip.
Sounds like that's the best thing for now.
OK, I'd really appreciate if someone took a look. I've now enabled weak_and_warn, and the Python 3.9 job on Ubuntu uses numpy==1.26.4 (all other jobs use numpy>=2). One test fails, which I cannot reproduce locally (neither on macOS nor on Linux).
The Windows jobs all emit a warning related to tk (see here), but I think these warnings have always been there (not a result of this PR).
Another question that came up: is the Debian i386 job still needed? It runs the tests with Python 3.7, which is not supported anymore.
Finally, and this is a question for when all other issues have been resolved, the test matrix is rather large. Is it really necessary to test on all combinations of OSs and Python versions?
Since uv has a new solver which now by default behaves like pip (https://github.com/astral-sh/uv/pull/9868), I'll revert to using uv sync and uv run again (will take a little time though). I'd appreciate any responses to my questions, because these are not affected by the resolution strategy.
Alright, this seems to be working now. @bemoody @tompollard it would be great if you could take a look and merge if you're happy with the changes. A quick follow-up release with these changes would then be super useful too! Thanks!
