avoid string version comparisons in external.qt

[minrk]

We have learned from pyzmq that one should always parse version strings
before comparing them.

[takluyver]

LooseVersion is not necessarily comparable on Python 3 (whereas StrictVersion is). Something like V('1.0.dev') > V('1.0.3') will throw a TypeError. I don't know what kind of pre-release version numbers PySide & PyQt use, though.

[minrk]

so I guess we have to write our own version comparison? I hate Python 3's strict comparison rules so much.

Something like:

import re
component_re = re.compile(r'(\d+ | [a-z]+ )', re.VERBOSE)
def V(vstr):
    vlist = component_re.findall(vstr)
    for i in range(len(vlist)):
        try:
            vlist[i] = int(vlist[i])
        except ValueError:
            vlist[i] = float('inf')
    return tuple(vlist)

which would always give a tuple of numbers, interpreting any text ('dev', etc) as infinite (2.1dev will always evaluate as greater than 2.1.x).

[minrk]

I added a NumericalVersion that should always be comparable, regardless of version string and Python version.

[takluyver]

There isn't really a consistent way to compare pre-release versions without knowing about the project's practices. e.g. your implementation implies that 0.13.dev > 0.13.1, but we ourselves use 0.13.dev < 0.13.1 for IPython. That's probably why LooseVersion isn't always comparable - there's no right way to do it.

Looking at their source code, it looks like PySide pre-releases would have a version like 1.1.2~alpha1 - which is comparable, but strictly less than 1.1.2. (ref). PyQt appears to go with snapshot-4.10-f0118624625e (from a development snapshot tarball) - which can't sensibly be compared to anything.

[minrk]

I don't actually care that dev versions get compared correctly, as long as they don't raise an error or get interpreted as too old. Anyone running a dev version other than current latest of any given package should not be considered a supported use case. In this way, a snapshot will always pass the minimum version check, and rightly so.

we ourselves use 0.13.dev < 0.13.1 for IPython

We actually use 0.13dev on both sides of 0.13.0. But the case remains that nobody using X.Y.dev of any version other than today's is valid. It seems to me to always be appropriate to interpret dev as 'latest'.

[takluyver]

Fair enough. I'd be inclined to compare LooseVersion and catch the error, but I think this should work fine as well.

[minrk]

If we went with LooseVersion, what should we do if the comparison fails?

[takluyver]

From your description, I think we can just silence the error, so it accepts
any pre-release version that it can't compare.

[minrk]

like this?

def check_version(v, check):
    """check version string v ≥ check

    if dev tags result in TypeError for string-number comparison,
    it is assumed that the dependency is satisfied.
    Users on dev branches are responsible for keeping their own packages up to date.
    """
    try:
        return LooseVersion(v) >= LooseVersion(check)
    except TypeError:
        return True

[minrk]

check_version added instead of NumericalVersion

[takluyver]

Yep, that looks good to me.

Do we want to leave NumericalVersion and version_tuple around, or just use check_version wherever we want to do this?

[minrk]

I'll remove NumericalVersion

[minrk]

unused code removed, should be ready to merge.

[takluyver]

Looks good to me, merging now.