Re: Don`t upgrade pip
Леонид Сергеевич <7matrix3@gmail.com> writes:
> DEPRECATION: reportbug 7.5.3-deb10u1 has a non-standard version number. pip
> 24.0 will enforce this behaviour change. A possible replacement is to
> upgrade to a newer version of reportbug or contact the author to suggest
> that they release a version with a conforming version number. Discussion
> can be found at https://github.com/pypa/pip/issues/12063
> WARNING: There was an error checking the latest version of pip.
Interestingly, if I'm reding the specification correctly, 7.5.3-deb10u1 is
a valid semver version (although it indicates a pre-release, incorrectly
in this case). PEP 440 is more restrictive than semver in that respect,
though.
Unfortunately, I don't see a good PEP 440 version number for what
reportbug versioning is trying to do. It's sort of a post-release, but
.postN only allows a single number. I'm not sure that there's anything
much better than 7.5.3.10.1, which unfortunately requires more human
interpretation of the last two segments (and also isn't a valid semver,
which probably doesn't matter a lot but which is unfortunate).
With my day job hat on, I think this is a good change for the Python
ecosystem as a whole. I maintain software that has to parse Python
package version numbers to check for security updates, and dealing with
non-standard version numbers is a real pain. I just wish PEP 440 were
aligned with semver and that both standards were a bit richer. Debian has
dealt with a lot of versioning challenges that neither standard seems to
have addressed, such as multiple named versioning streams that nonetheless
need to maintain a total order, although our standard is also looser than
would be ideal for PyPI since we try to allow for nearly arbitrary
upstream version numbers.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: