Repository navigation
Pin numpy<2 in v6.0? #15393
Description
We could do something like #15206 (cc @neutrinoceros) but for v6.0.x when we branch it out. Or do you think v6.0 would be okay with numpy 2.0?
The timing is tricky because numpy 2.0 and astropy 6.0 could possibly happen around the same time, but I don't know which one would come out first.
@astropy/astropy-project-release-team should probably make this call at release time.
Reacted by Clément Robert
Activity
mhvk commentedon Sep 27, 2023
I really hope we won't have to...
bsipocz commentedon Oct 3, 2023
Why would you do this?
mainworks with 2.0dev, and this upper limiting was never the approach for any other versions.pllim commentedon Oct 3, 2023
In case we have to release before numpy 2.0 comes out. In that case, numpy 2.0.dev would still be in flux and we cannot guarantee that our release would be compatible with numpy 2.0 stable. I think.
bsipocz commentedon Oct 3, 2023
But that could/should be true for any other not yet released versions from cpython down to the bottom of the dependency list (as well as for any releases in the past with an upcoming numpy release looming over them), yet no upper limits are around for any packages (rightfully so).
pllim commentedon Oct 3, 2023
That is not quite true.
contourpypinsnumpy<2even in their dev branch, causing me pain with testing both matplotlib dev and numpy dev in the same job.Other packages also max pin a bunch of stuff (not numpy in this case) in their dev branches, so such practice is not unprecedented; for example:
bsipocz commentedon Oct 3, 2023
I meant that astropy didn't do upper limits in the past. I know that others doing it, and I very well know that it causes pain all over.
https://iscinumpy.dev/post/bound-version-constraints/
TL;DR:
pllim commentedon Oct 3, 2023
Ah, okay, that is true. But this is the first time we have to deal with numpy 1 -> 2. 🤷
bsipocz commentedon Oct 3, 2023
I added the TL;DR, still don't see why it should be there. It should not be a preventative step but be done only if there are known and certainly expected issues. Which IMO is not the case.
bsipocz commentedon Oct 3, 2023
(And I don't think the practice of a user-level library/app like bqplot should be applicable here. There are a lot of package depending on the astropy library, adding an upper limit here has a consequence on all of those, while it's less the case for things that are targeting the end-user)
mhvk commentedon Oct 4, 2023
I agree with @bsipocz that unless we know numpy 2.0 does not work, we should not have a limit. I definitely share the slight despair at the numpy changes for 2.0, but guess we'll just have to keep fixing any problems and then make a new point release... (and I'll continue to try to be quick with helping out!).
One other thing that I think might help (I can do it), is to ask the numpy folks what more is in the pipeline shortly before our release.
pllim commentedon Oct 4, 2023
Okay, I think the conclusion so far is "no" but I will let @astropy/astropy-project-release-team decide if they want to keep this open or close it. Ultimately, burden of any extra releases would fall to them.
saimn commentedon Oct 4, 2023
I don't see a reason to pin now, we will see when we get closer to numpy/astropy releases but would be better if we can have a release that is directly compatible with Numpy 2.0.
bsipocz commentedon Oct 4, 2023
I'm certain changes will slow down as Mateusz' internship will wrap up soon and a lot of the 2.0 plans had already happened.
Big ones coming are:
numpy/coretonumpy/_core[NEP 52] numpy/numpy#24634;Or just have a look at the roadmap: NumPy 2.0 Roadmap
astrofrog commentedon Oct 11, 2023
I think we don't need to pin
pllim commentedon Oct 11, 2023
OK both release managers said no, so closing. Thanks for the discussions, all!