id summary reporter owner description type status priority milestone component version resolution keywords cc launchpad_bug 2499 Poor error reporting when verlib.suggest_normalized_version returns None daira daira " 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" defect new normal 1.11.0 packaging 1.10.1 error versions verlib packaging