https://github.com/numpy/numpy/pull/21601 has been merged, but we should make sure everyone is on board with the updated wording. The intent was to resolve the discrepancy I think Aaron is referring to (the text spoke of the 18mo release cycle in present tense) and to justify sticking with 42months despite the upstream change.
I think it is good for the overall community if we have a (mostly) unified position on this, but if projects are going to disregard NEP 29 I am personally happy for them to run faster :) Tom On Thu, May 26, 2022 at 7:08 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Thu, May 26, 2022 at 4:41 AM Aaron Meurer <asmeu...@gmail.com> wrote: > >> > I have seen problems popping up already in a few places with latest >> numpy not supported what is still the most commonly used Python version >> (don't have links, sorry - but they were real packaging-related issues). So >> I don't think it makes sense to shorten the time window. I also don't think >> there's a need to drop one version that's urgent - it's some effort and CI >> time, but the balance is decent right now. >> >> It's hard to say the balance is decent right now if the faster cadence >> isn't even in full effect yet (as I noted in my original email). >> >> Generally I would say that dropping support only means that users of >> older versions would simply need to use an older version of the >> library. >> > > That is not the full story unfortunately. The Python packaging tooling > (Pip, Poetry et al) is imperfect, so if other packages depend on NumPy and > then at install time a tool figures out that latest NumPy cannot be used, > or somewhere there's an upper bound in the version constraints explicitly, > some things tend to go wrong. > > >> >> > There was a lot of discussion around how big the window should be with >> 42mo being about in the middle of what people advocated for. I am aware of >> institutions that are on an every-other Python upgrade pattern (py37 -> >> py39 -> (expected) py311) so always having at least 3 Pythons in the window >> is important. Based on what we have seen so far, I still think 42mo is a >> good choice, but do not think we have seen it in operations long enough to >> draw any conclusions (the downside of year-scale planning is you need to >> wait years to see if it worked out like you expected!) and hence do not >> think we should make any changes to the time window for another few years. >> That said, I am currently sympathetic to making the window longer and >> against making it shorter. >> >> The reason I brought this up is because we were looking at whether it >> makes sense to use NEP 29 for SymPy. Obviously we aren't bound to >> using it, but given this apparent discrepancy in the text (which still >> exists), > > > What discrepancy? > > Cheers, > Ralf > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: tcasw...@gmail.com > -- Thomas Caswell tcasw...@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
