Bug#1014890: ITP: python3-looseversion -- Version numbering for anarchists and software realists
on January 4th of 2023 you retitled this RFP to ITP.
> ITP: python3-looseversion -- Version numbering for anarchists and
software realists
Do you have an early package code or python3-looseversion to share (on
debian salsa or else)?
I will have to create such a package otherwise as salt 3006 depends
upon python3 looseversion (I am building it based upon the salt 3005
deb pacakging from
openmediavault https://github.com/openmediavault/packages/tree/master/pool/main/s/salt
).
So even if you only did an early frame of it that would avoid duplicate
effort.
Cheers,
Alban
On Wed, 13 Jul 2022 14:54:11 -0400 Yaroslav Halchenko
<debian@onerussian.com> wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-python@lists.debian.org
>
> * Package name : python3-looseversion
> Version : 1.0.1
> Upstream Author : Chris Markiewicz <effigies@gmail.com>
> * URL : https://github.com/effigies/looseversion
> * License : Python
> Programming Lang: Python
> Description : Version numbering for anarchists and software
realists
>
> A backwards/forwards-compatible fork of
distutils.version.LooseVersion,
> for times when PEP-440 isn't what you need.
> .
> The goal of this package is to be a drop-in replacement for the
original
> LooseVersion. It implements an identical interface and comparison
logic to
> LooseVersion. The only major change is that a
looseversion.LooseVersion is
> comparable to a distutils.version.LooseVersion, which means tools
should not
> need to worry whether all dependencies that use LooseVersion have
migrated.
> .
> If you are simply comparing versions of Python packages, consider
moving
> to packaging.version.Version, which follows PEP-440. LooseVersion is
better
> suited to interacting with heterogeneous version schemes that do not
follow
> PEP-440.
>
> This package would be useful as we plan for adding support for Python
3.12
> which would remove distutils.version.LooseVersion and some packages
would need
> to "adjust" somehow. In our DataLad project we likely would just go
the way
> of using this LooseVersion instead of coming up with some "more
proper" solution.
>
>
Reply to: