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

New Issue

tahoe-lafs · 2015-09-12T00:49:25Z

daira commented

2015-09-12 00:49:25 +00:00

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 [#2499]in 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

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 [#2499]in 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

tahoe-lafs added the

labels 2015-09-12 00:49:25 +00:00

tahoe-lafs added this to the undecided milestone 2015-09-12 00:49:25 +00:00

daira commented

2015-09-12 00:51:24 +00:00

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

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

tahoe-lafs added

enhancement

and removed

task

labels 2015-09-12 00:52:01 +00:00

tahoe-lafs modified the milestone from undecided to eventually

2015-09-12 00:52:01 +00:00

warner commented

2015-09-12 19:24:57 +00:00

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 :).

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 :).

Sign in to join this conversation.