Poor error reporting when verlib.suggest_normalized_version returns None

[daira]

<warner> I'm trying to test tahoe (trunk) against a foolscap branch that I'm working on <warner> and I'm thwarted by packaging and setuptools, again [...] <warner> ... "PYTHONPATH=/path/to/my/foolscap/tree ./bin/tahoe" ... currently emits: PackagingError: could not parse actual version '0.8.0+12.g1fdaa3e.dirty' of foolscap from '/Users/warner/stuff/python/foolscap' due to TypeError: expected string or buffer <warner> Warning: version number '0.8.0-12.g1fdaa3e.dirty' found for dependency 'foolscap' by pkg_resources could not be parsed. The version found by import was '0.8.0+12.g1fdaa3e.dirty' from '/Users/warner/stuff/python/foolscap'. pkg_resources thought it should be found at '/Users/warner/stuff/python/foolscap'. The exception was PackagingError: could not parse '0.8.0-12.g1fdaa3e.dirty' due to TypeError: expected string or buffer <warner> I don't know where that TypeError is coming from, or what it's getting that isn't a string <warner> I thought it might have to do with some Versioneer changes I made at one point which cause versions to sometimes be unicode, but hardcoding the version doesn't make the tahoe/packaging error go away

warner tries to even figure out what our 'setup.py build' does these days <warner> ah, found it. Tahoe's verlib.suggest_normalized_version() doesn't recognize Versioneer's (setuptools-compatible) "0.8.0+12.g123abc.dirty" as a parseable version, and returns None <warner> then verlib.NormalizedVersion(that) explodes when the regexp tries to parse the None <warner> delete.. it.. all.. <warner> actually now it's reminding me of the HHGTTG scene where the intergalactic cruise is grounded for centuries whilst waiting the availability of lemon-soaked paper napkins <warner> the version can't be parsed, therefore refuse to run <warner> this version-parsing code is really getting in my way

[daira]

For once, a packaging error that isn't directly setuptools' fault. (The need for the version checks in the first place is setuptools' fault.)

It's not correct to refuse to run here, because the purported version from pkg_resources was exactly equal to the imported version, so normalisation was unnecessary. Will fix.

I'll also fix the error reporting in the case where the versions aren't exactly equal and can't be normalised.

[daira]

Review needed for ​https://github.com/tahoe-lafs/tahoe-lafs/pull/188.

[Daira Hopwood <daira@…>]

In a4dfc31a19afd39c27120fac0588250a1f5f48e9/trunk:

Avoid spurious errors when an imported version is consistent with pkg_resources
but not parseable; also improve related error reporting. fixes ticket:2499

Signed-off-by: Daira Hopwood <daira@…>

[warner]

Milestone renamed