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