Add looseversion to PyPA

Packaging
1

Hi all,

With distutils being removed, the one thing that I couldn’t find a suitable replacement for was distutils.version.LooseVersion, as packaging.version.LegacyVersion was being deprecated and in any event didn’t have quite the same semantics.

So I just pulled it out into GitHub - effigies/looseversion: A backwards/forwards-compatible fork of distutils.version.LooseVersion and it’s on PyPI: looseversion · PyPI.

100% of the goal is to allow people to keep their existing code working by changing an import line and adding a dependency, not to “improve” it in any way. I have made only two changes to the code:

  1. Added compatibility with distutils.version.LooseVersion so that they can be freely compared if they somehow end up in the same scope.
  2. Added type annotations.

I guess a couple big projects started to depend on it, as I got an email from PyPI indicating that it’s a “critical project”. It seems I need to attract an additional maintainer to make me less of a single point of failure.

I was wondering if it would be appropriate to move it under an organization with wider visibility like PyPA, which might make it easier to attract another maintainer and give others the authority to assign new maintainers if I fall off the internet.

2

Ou of curiosity, how does LooseVersion manage versions? The README didn’t make that clear and I’ve never heard of that module before. The only point of comparison I have is SemVer (not any package in particular but the concept) and I’m wondering how you get “looser” than SemVer while somehow (afaict) still get som structure in your version management.

3

I suppose I didn’t add that to the docs because it’s really only intended for people who have been using it and don’t want to have to introduce bugs from a changed semantics because distutils is gone.

The Python docs no longer seem to render the docstring anywhere, but it is included in PEP 386 – Changing the version comparison module in Distutils | peps.python.org.

You can also find them the docstring and an extensive comment in the code:

Finally, you can see the mapping from string to list here:

These lists are what are actually compared.

1 Like
4

Personally, I’m inclined to say it shouldn’t go under the PyPA banner, as it’s explicitly intended to allow people to not follow the accepted standard for versions. We’ve just removed “legacy version” support from packaging, so adding it back in a different project seems to send mixed messages.

Having said that, I can see the value of this as a transitional mechanism, so it’s not that I don’t see value in having the library.

3 Likes
5

FWIW I don’t think it’s transitional. If someone is working with Python packages, they should use packaging.version. The main use case I have is for managing non-Python resources where raising exceptions because they don’t follow PEP440 is counterproductive.

I do see your point that we shouldn’t imply that it’s for use in Python packaging by putting it under PyPA. Thanks for the feedback.

4 Likes
6

For that use case, I don’t think the class should be called a loose version. It’s not loose, it’s conforming to a different standard than PEP 440. Or call it something like GenericVersion with documentation explicitly noting that it’s for parsing versions of non-Python projects.

If the use case you’re targetting isn’t parsing old, pre-PEP440 Python package versions (the transitional case I assumed was the intention) then the fact that it’s historically from distutils is basically irrelevant at this point, and the current documentation needs updating to note that Python packages are not the intended use for this.

7

FWIW, I’ll also point out that the looseversion behaves differently from the LegacyVersion class that lived in packaging.version.

I’ll echo the sentiment around not sending mixed messaging around what to do about the versions in your tooling/packages.