Test on numpy 2.0
Opened this issue · 8 comments
Description
We may need to pin <2.0 until any break changes are fixed (or we could be very lucky and nothing would happen). First step is to test, which we can do with RC versions
Ok, I can put together a repodata patch to make it retroactive on conda-forge. The first step is to add it to our pyproject.toml, and ideally make a release containing the pin. (Conda-forge core prefers to see such retroactive changes being made for something that's already in the feedstock, so that's why a release would be good.)
Any idea on the timeline before the non-rc release drops?
Any idea on the timeline before the non-rc release drops?
Couldn't find anything conclusive, but sounds like soon: numpy/numpy#24300
On the conda-forge side I wrote a repodata patch, and then when I tested it didn't actually do anything...
Happily, in terms of Numpy, the conda-forge infrastructure currently automatically pins numpy<2.0.a0 to ensure binary compatibility, so my repodata patch was redundant. 🎉
There's the question of how to move forward once 2.0 becomes available, and this I'm less sure about. I'm testing adding a pin in conda-forge/pytensor-suite-feedstock#88, but there's the possibility that this interferes with the conda-forge magic (see conda-forge/pytensor-suite-feedstock#35).
My recommendation on how to proceed is that we keep an eye on the pins by checking the artifacts in conda-forge/pytensor-suite-feedstock before merging any of the version update PRs.
I'm very relieved that there is no threat of PyTensor breaking as soon as Numpy 2 is released. 😅
Here us the issue to track ecosystem compatibility with numpy 2.0 numpy/numpy#26191 (comment)
Hmmm, when looking around, I had stumbled on Aesara fork of Theano, but somehow not pytensor. The one potentitially complicated change is that right now I removed MapIter, because it is terribly slow (in the public API form) but having it public API means dragging.
Aesara was saying that they wanted to get rid of that code anyway, and I am almost betting that calling back into Python might be better than using PyArray_MapIter (e.g. using ufunc.at() is usually now fast, but of course not when running on some older NumPy versions)
Please let me know if this is a big issue, or if I can give some pointers in how to just replace the whole thing.
Is there a NumPy 2 tracking issue for PyMC as well?
Searched for one, but didn't find it (though could very easily have missed it)
Is there a NumPy 2 tracking issue for PyMC as well?
Searched for one, but didn't find it (though could very easily have missed it)
No, the only blocker for PyMC is PyTensor compatibility with numpy 2.0 (I think)