I guess this is also a mandatory read after Henry's blog post appeared that we had an extensive discussion with Python devs https://discuss.python.org/t/requires-python-upper-limits/12663
On Tue, May 7, 2024 at 11:35 AM Sebastian Berg <sebast...@sipsolutions.net> wrote: > On Tue, 2024-05-07 at 15:46 +1000, Juan Nunez-Iglesias wrote: > > On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote: > > > This problem could have been avoided by proper use of upper bounds. > > > Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug > > > in scikit-image (definitely for ABI reasons, and arguably also for > > > API reasons). It would really be useful if downstream packages > > > started to take adding upper bounds correctly more seriously. E.g., > > > SciPy has always done it right, so the failure mode that this > > > thread is about doesn't exist for SciPy. That said, this ship has > > > sailed for 2.0 - most packages don't have upper bounds in some or > > > all of their recent releases. > > > > I don't think this is a downstream problem, I think this is a "PyPI > > has immutable metadata" problem. I'm a big fan of Henry Schreiner's > > "Should You Use Upper Bound Version Constraints" < > > https://iscinumpy.dev/post/bound-version-constraints/>, where he > > argues convincingly that the answer is almost always no. This > > highlighted bit contains the gist: > > > > Yes, that is all because of `pip` limitations, but those limitations > are a given. And I think it is unfortunate/odd that it effectively > argues that the lower in the stack you are, the fewer version you > should support. > > But, with the clarification we have that there may be a lot of packages > that never support both Python 3.9 and NumPy 2. > That means not publishing for 3.9 may end up helping quite a lot of > users who would have to downgrade NumPy explicitly. > > If that seems the case, that is an unfortunate, but good, argument for > dropping 3.9. > > I don't have an idea for how many users we'll effectively help, or if > we do the opposite because an application (more than library) wants to > just use NumPy 2 always but still support Python 3.9. > But it seems to me that is what the decision comes down to, and I can > believe that it'll be a lot of hassle saved for `pip` installing users. > (Note that skimage users will hit cython, so should get a relatively > clear printout that includes a "please downgrade NumPy" suggestion.) > > - Sebastian > > > > > > > > A library that requires a manual version intervention is not > > > broken, it’s just irritating. A library that can’t be installed due > > > to a version conflict is broken. If that version conflict is fake, > > > then you’ve created an unsolvable problem where one didn’t exist. > > > > Dropping Py 3.9 will fix the issue for a subset of users, but > > certainly not all users. Someone who pip installs scikit-image==0.22 > > on Py 3.10 will have a broken install. But importantly, they will be > > able to fix it in user space. > > > > At any rate, it's not like NumPy (or SciPy, or scikit-image) don't > > change APIs over several minor versions. Quoting Henry again: > > > > > Quite ironically, the better a package follows SemVer, the smaller > > > the change will trigger a major version, and therefore the less > > > likely a major version will break a particular downstream code. > > > > In short, and independent of the Py3.9 issue, I don't think we should > > advocate for upper caps in general, because in general it is > > impossible to know whether an update is going to break your library, > > regardless of their SemVer practices, and a fake upper pin is worse > > than no upper pin. > > > > Juan. > > _______________________________________________ > > 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: sebast...@sipsolutions.net > > > _______________________________________________ > 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: ilhanpo...@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
