homepage

$ python2.7 -c 'from distutils.version import LooseVersion as V; print V("a") > V("1")'
True
$ python3.2 -c 'from distutils.version import LooseVersion as V; print(V("a") > V("b"))'
False
$ python3.2 -c 'from distutils.version import LooseVersion as V; print(V("a") > V("1"))'
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "/usr/lib/python3.2/distutils/version.py", line 70, in __gt__
 c = self._cmp(other)
 File "/usr/lib/python3.2/distutils/version.py", line 343, in _cmp
 if self.version < other.version:
TypeError: unorderable types: str() < int()

Thanks for the report. How did you find this? According to the doc of LooseVersion, 'a' is not valid, so I would like a real example to accept this as a bug.

On May 23, 2012, at 10:13 PM, Éric Araujo wrote:
>
>Thanks for the report. How did you find this? According to the doc of
>LooseVersion, 'a' is not valid, so I would like a real example to accept this
>as a bug.
It works in Python 2.7 so I think it was viewed as a regression.
Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.version import LooseVersion as v
>>> v('a') < v('0')
False
But if 'a' is invalid, then LooseVersion should refuse to accept it in its
constructor, right?

Hello, as a GSoC student, I'm working on PyPI to Debian repository converter. I wanted to compare versions of packages available in PyPI and it broke while comparing appwsgi, wsgi-design ('default') and gar ('prototype.1') versions.

> Hello, as a GSoC student, I'm working on PyPI to Debian repository converter.
Great! I hope you’re aware of previous efforts like stdeb (unfortunately requires setuptools) and py2rpm (for rpm systems but some parts can be inspiration, like the download code). I follow debian-python so we may encounter each other there.
> I wanted to compare versions of packages available in PyPI and it broke while comparing appwsgi,
> wsgi-design ('default') and gar ('prototype.1') versions.
I wonder why you need to compare versions from different projects. What is "it" in "it broke"? If it’s a regular distutils command, please paste the full command and log; if you meant you used the LooseVersion class in your code, then I’m afraid I will say this won’t be fixed: this is not a public class. distutils2.version however does contain a public class that implements PEP 386; even if the project is still in alpha (and I want to make a few renamings and API changes), you can still use it (and when I break your code a quick look at the CHANGES file will help you update).

About Barry’s reply:
> But if 'a' is invalid, then LooseVersion should refuse to accept it in its constructor, right?
It’s complicated. The doc does not say much, the docstring however clearly states that versions should start with a digit, but a ton of projects use invalid-but-not-rejected formats. distutils2 makes a clean break with clear rules (PEP 386); I’m not sure it would be acceptable for distutils to suddenly reject these versions. It sounds useful but even with that change people would not always comply with PEP 386, so better let them use broken versions with distutils and force a switch to a fully compliant format with d2. Does that make sense?

On May 24, 2012, at 03:03 PM, Éric Araujo wrote:
>> But if 'a' is invalid, then LooseVersion should refuse to accept it in its
>> constructor, right?
>It’s complicated. The doc does not say much, the docstring however clearly
>states that versions should start with a digit, but a ton of projects use
>invalid-but-not-rejected formats. distutils2 makes a clean break with clear
>rules (PEP 386); I’m not sure it would be acceptable for distutils to
>suddenly reject these versions. It sounds useful but even with that change
>people would not always comply with PEP 386, so better let them use broken
>versions with distutils and force a switch to a fully compliant format with
>d2. Does that make sense?
It does, but in that case, I think the comparison should continue to succeed,
with whatever results it produces in Python 2.7.

Hi, I'm attaching a patch that fixes this issue:)

I had a wrong return value in one of unit tests, fixed.

> I think the comparison should continue to succeed,
> with whatever results it produces in Python 2.7
The point I was trying to make is that this is not something done on purpose, nor useful or guaranteed, but only a side effect of 2.x’s mixed comparisons. As undefined behavior, I don’t want to change 3.x to match it.
Natalia, could you reply to my questions in msg161515 ? Thanks.

As far as a real-world example is concerned, if you're using git-describe to generate your version numbers, you can pretty easily end up with something like "ab25c6fe95ee92fac3187dcd90e0560ccacb084a".

Thanks Dwayne. I think that most tools (e.g. setuptools) generate things like 1.0.2+gitab25c6fe95ee92fac3187dcd90e0560ccacb084a i.e. real version set by maintainer + hash, not just the hash, so I am still not convinced a change is needed.

"git describe --tags --always" will return a bare commit id if there is no previous tag. This is pretty common to have when you're working on a new package that hasn't been released yet:
$ git init
Initialized empty Git repository in /tmp/repo/.git/
$ touch foo
$ git add foo
$ git commit -m 'Initial commit'
[master (root-commit) cd7dd74] Initial commit
 0 files changed
 create mode 100644 foo
$ git describe --tags --always
cd7dd74
$ git tag v1.0
$ git describe --tags --always
v1.0

> As far as a real-world example is concerned, if you're using
> git-describe to generate your version numbers, you can pretty easily
> end up with something like "ab25c6fe95ee92fac3187dcd90e0560ccacb084a".
And how are you supposed to compare that with anything else?
I think `V("a") > V("b")` should raise TypeError in Python 3.

Don’t know if you’ve seen my previous message:
I think that most tools (e.g. setuptools) generate things like 1.0.2+gitab25c6fe95ee92fac3187dcd90e0560ccacb084a i.e. real version set by maintainer + hash, not just the hash.
I was talking about a version number set by the author, typically 0.1, not a VCS tag.

> Don’t know if you’ve seen my previous message:
I'm a bit lost, how are you replying to? :)

Or, rather, who :-S

I was replying to Dwayne.

I have a more realistic example of this bug. In the docstring for distutils.LooseVersion, it says '1.5.1' and '3.2.p10' are both valid version numbers. If instead of '3.2.p10', we use '1.5.p10', the following occurs -
>>> v1 = LooseVersion('1.5.1')
>>> v2 = LooseVersion('1.5.p10')
>>> v1>v2
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "C:\Python33\Lib\distutils\version.py", line 70, in __gt__
 c = self._cmp(other)
 File "C:\Python33\Lib\distutils\version.py", line 343, in _cmp
 if self.version < other.version:
TypeError: unorderable types: int() < str()
>>> v1.version
[1, 5, 1]
>>> v2.version
[1, 5, 'p', 10]
The reason it occurs is pretty clear when the .version list is printed. (That's also explains why I had to use 1.5.p10 instead because otherwise the comparison would not proceed past the first element of both lists.)
In my real-life example, I'm trying to compare '1.1.0-3' and '1.1.0-beta-10'.
>>> v3=LooseVersion(ll[0])
>>> v4=LooseVersion(ll[1])
>>> v3>v4
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "C:\Python33\Lib\distutils\version.py", line 70, in __gt__
 c = self._cmp(other)
 File "C:\Python33\Lib\distutils\version.py", line 343, in _cmp
 if self.version < other.version:
TypeError: unorderable types: int() < str()
>>> v3.version
[1, 1, 0, '-', 3]
>>> v4.version
[1, 1, 0, '-', 'beta', '-', 10]

I’m still torn between improving this as best as we can and waiting for clean new spec and code. Last PyCon Nick said he had a PEP in mind to specify how distutils would be updated to support new standards; I think we’ll revisit this issue when that policy exists.

Unfortunately, the current likely answer re updating vanilla distutils to handle the new standards is "we won't". The backwards compatibility issues involved are just too hairy for us to start enabling by default in the standard library, and I've become convinced that coupling the build and installation tools to the language version is fundamentally a mistake anyway (hence the bundling approach in PEP 453).
Instead, we're hacking around the metadata side of the problem through the fact that pip always runs setup.py under setuptools (even if the setup.py only used vanilla distutils) and encouraging the use of cross-version compatible tools in other cases (with setuptools being the current de facto choice, since the distlib APIs are still considered experimental).
For this particularly case, I don't see any harm in bringing distutils in Py3 back in line with Py2, especially if it's also consistent with setuptools.

> Unfortunately, the current likely answer re updating vanilla distutils to handle the new
> standards is "we won't". The backwards compatibility issues involved are just too hairy
> for us to start enabling by default in the standard library, and I've become convinced
> that coupling the build and installation tools to the language version is fundamentally a
> mistake anyway (hence the bundling approach in PEP 453).
This makes sense. Given that distutils is still a basic packaging solution included in the stdlib, and no longer under a feature freeze, what kind of improvements do you think it can get?
* Can we switch to SSL with certificate checking? I think it’s a big yes.
* Can we improve the UI of some commands in a backward-compatible way? (Existing example: allowing the upload command to send an existing file, instead of requiring to build and upload in one command line)
* Can we add new commands like upload_docs and test (that would just run unittest discovery)? It may be judged wasted time, if the whole world uses setuptools (but does it?).
* Can we add support for wheel? Building extensions with the stable ABI? New version or metadata formats?
> For this particularly case, I don't see any harm in bringing distutils in Py3 back in
> line with Py2, especially if it's also consistent with setuptools.
It’s basically adding code to support comparison of mismatched types, i.e. time and effort to add something similar to a Python 2 design flaw. (setuptools’ version class is different from both distutils’ classes.)

Forgot one:
* Can we add tar.xz support to sdist?

Yes, I agree we should allow backwards compatible distutils RFEs if people
want to work on them. It's not going away any time soon, we just need to be
careful with any internal refactoring.

Hi,
Just wanted to know if there was anything new on this?
When managing softwares version we often are not at all master of the naming convention used: we just have to deal with it.
"LooseVersion" was very nice as it would take any string as input and do "the best" with it.
Now that it's broken for some type of version string, it become quite useless.
I overloaded the comparison part more or less using the Natalia patch idea (but done after the argument split). But shouldn't that be default?
Thanks.

I am inclined to reject the patch.
LooseVersion is not meant to be a general utility for all modules; I know it’s used in the wild but projects should define their parsing/comparison function or make up a specific module for that.
If the problem happens from distutils or pip when comparing real distributions that really define version='a' and version='1', then modern setuptools or flit or twine will warn about that.

If you want to make LooseVersion a tiny bit more robust, I suggest to borrow the algorithm from the platform module (see issue26544).

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools