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: arch...@mail-archive.com
