consider switching from 'verlib' to 'packaging' for version checks

[daira]

dstufft: daira: you're using verlib? You probably want to use ​https://warehouse.python.org/project/packaging/

daira: dstufft: yes, it was what was available at the time

dstufft: yea makes sense

daira: is there a compelling reason to switch?

daira: I guess we could use ​https://pypi.python.org/pypi/packaging rather than copying the code as we did with verlib...

daira: except that how do we check the version of the 'packaging' dependency in that case?

daira: I think I'd rather leave this well alone

dstufft: daira: the reason you're getting a None [in #2499] is that verlib doesn't support PEP 440 and your version it was passing into it was a PEP 440 version

dstufft: that's the root cause of that error

daira: ah

daira: so that is potentially a good reason to switch

daira: if more packages are going to start using only-PEP-440-compatible versions

dstufft: packaging is designed to either be put as a dependency OR bundled directly

dstufft: it has no (and will never have) any dependencies of it's own, and is only pure python

dstufft: both pip and setuptools are using it now (bundled)

daira: I see

daira: I think we can bundle it then

daira: I'll file a ticket

[daira]

dstufft: daira: if you're doing anything with version specifiers (like >=1.0) packaging has those too

dstufft: same implementation as both pip and setuptools is using now too

daira: Yes, we are

daira: so that's a very good reason to switch

[warner]

Or we could just delete all that code :)

I think this this was prompted by #2499, which was prompted by my IRC-logged frustration when I was unable to test Tahoe against a locally-modified version of Foolscap, because Tahoe was being unnecessarily picky about versions. I spent half an hour fighting with a tool that should have merely said "I can't figure this out, sorry" instead of throwing exceptions and thwarting my efforts to get work done.

So let me propose a guideline: all changes to the version displaying/checking/freaking-out-ing code in Tahoe should monotonically decrease in SLOC count with each commit. (er, be non-increasing.. you know what I mean). If 'packaging' is smaller/simpler and less-makes-it-hard-to-get-work-done than 'verlib', great. But I'm not really convinced that runtime comparison of versions is so important that it should make development more difficult. The next version of Foolscap is likely to break something in Tahoe because I was unable to test them together before releasing, and that's a bummer, because as far as I can tell Tahoe is the only user of Foolscap :).