#2499 closed defect (fixed)

Poor error reporting when verlib.suggest_normalized_version returns None

Reported by: daira Owned by: warner
Priority: normal Milestone: 1.12.0
Component: packaging Version: 1.10.1
Keywords: error versions verlib packaging Cc:
Launchpad Bug:

Description (last modified by 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

Change History (6)

comment:1 Changed at 2015-09-04T09:10:21Z by daira

  • Description modified (diff)

comment:2 Changed at 2015-09-04T09:10:47Z by daira

  • Description modified (diff)
  • Status changed from new to assigned

comment:3 Changed at 2015-09-04T09:16:25Z by 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.

Last edited at 2015-09-04T09:16:48Z by daira (previous) (diff)

comment:4 Changed at 2015-09-12T00:07:21Z by daira

  • Owner changed from daira to warner
  • Status changed from assigned to new

comment:5 Changed at 2015-09-15T16:17:27Z by Daira Hopwood <daira@…>

  • Resolution set to fixed
  • Status changed from new to closed

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@…>

comment:6 Changed at 2016-03-22T05:02:52Z by warner

  • Milestone changed from 1.11.0 to 1.12.0

Milestone renamed

Note: See TracTickets for help on using tickets.