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 <deb...@onerussian.com> wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > * Package name : python3-looseversion > Version : 1.0.1 > Upstream Author : Chris Markiewicz <effig...@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. > >