Poor error reporting when verlib.suggest_normalized_version returns None #2499

New Issue

tahoe-lafs · 2015-09-04T09:08:57Z

daira commented

2015-09-04 09:08:57 +00:00

I'm trying to test tahoe (trunk) against a foolscap branch that I'm working on
and I'm thwarted by packaging and setuptools, again
[...]
... "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
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
I don't know where that TypeError is coming from, or what it's getting that isn't a string
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
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
then verlib.NormalizedVersion(that) explodes when the regexp tries to parse the None
delete.. it.. all..
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
the version can't be parsed, therefore refuse to run
this version-parsing code is really getting in my way

<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

tahoe-lafs added the

labels 2015-09-04 09:08:57 +00:00

tahoe-lafs added this to the 1.11.0 milestone 2015-09-04 09:08:57 +00:00

daira commented

2015-09-04 09:16:25 +00:00

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.

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 commented

2015-09-12 00:07:21 +00:00

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

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

Daira Hopwood <daira@jacaranda.org> commented

2015-09-15 16:17:27 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/a4dfc31a19afd39c27120fac0588250a1f5f48e9:

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@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/a4dfc31a19afd39c27120fac0588250a1f5f48e9](/tahoe-lafs/trac-2024-07-25/commit/a4dfc31a19afd39c27120fac0588250a1f5f48e9): ``` 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@jacaranda.org> ```

tahoe-lafs added the

fixed

label 2015-09-15 16:17:27 +00:00

Daira Hopwood <daira@jacaranda.org> closed this issue

2015-09-15 16:17:27 +00:00

warner commented

2016-03-22 05:02:52 +00:00

Milestone renamed

warner modified the milestone from 1.11.0 to 1.12.0

2016-03-22 05:02:52 +00:00

Sign in to join this conversation.