Log file Viewer

[21:01:26] <dstufft> jaraco: ping

[21:02:08] <jaraco> dstufft, pong

[21:03:44] <dstufft> jaraco: wanted to get your opinion on https://github.com/pypa/packaging/pull/5 - I Reversed my position and with that PR LegacyVersion and Version will be sortable together. I was having to add too many special cases throguhout the setuptools code base that it wasn't erally a special case. It doesn't use the pkg_resources style thing... just case insensitive string sorting but the difference is neglible I think looking at the actual sorting

[21:03:45] <dstufft> of things on PyPI

[21:05:09] <jaraco> dstufft, smart. I like it (esp. making LegacyVersion less than any Version)

[21:06:05] <dstufft> jaraco: cool, I'll merge that and update the PR and stuff then. that should remove any issues where people get exceptions from throwing stuff at parse_version too

[21:06:28] <dstufft> the only backwards incompat (other than sort order changes) thing then would be the fact it's a class not a tuple for that particular API

[21:06:38] <dstufft> class isntance*

[21:08:48] <jaraco> Here's why I thought having LegacyVersion implement the same pkg_resources tuple for the comparator:

[21:09:25] <jaraco> If it turns out that someone is relying on that behavior, they could easily cast every Version to a LegacyVersion, and then they would have 100% compatible ordering.

[21:10:00] <jaraco> But if LegacyVersion implements another ordering, that adds yet another ordering scheme to the mix.

[21:10:34] <jaraco> I would be okay with that, except then the documentation is much harder to write.

[21:10:45] <dstufft> jaraco: hmm, that's a reasonable point

[21:10:55] <dstufft> I can implement the old pkg_resources behavior

[21:11:22] <dstufft> I didn't think about the idea that someone can downcast to a LegacyVersion

[21:11:39] <dstufft> only reason I didn't was simplicitly sake, less code == less places for bugs :D

[21:12:00] <jaraco> And that's reasonable too.

[21:12:05] <jaraco> I guess there are two legacies here.

[21:12:25] <jaraco> 1. odd choice of version number, 2. support of that in parsing

[21:12:39] <jaraco> You've been focused on 1 and me on 2

[21:12:53] <jaraco> I like the idea of having LegacyVersion handle both.

[21:15:35] <dstufft> I guess the question is, what's the likelihood of someone wanting to get back the exact sort order used in previous versions of pkg_resources, and I don't really know the answer to that.

[21:15:36] <dstufft> HOWEVER

[21:15:50] <jaraco> I don't either.

[21:16:08] <dstufft> parse_version is pretty small I think... https://github.com/jaraco/setuptools/blob/master/pkg_resources.py#L2097-L2156 is all it takes unless I'm missing something

[21:16:14] <dstufft> so it shouldn't be a big deal

[21:16:24] <jaraco> That sounds right to me.

[21:18:23] <dstufft> yea so I can do that, even if nobody ever uses it, I don't think an additional ~23 lines of code is going to be a big deal

[21:18:48] <dstufft> jaraco: thanks!

[21:19:03] <jaraco> !em dstufft

[21:19:03] <pmxbot> Vi faras bonan laboron, dstufft!

[21:19:27] <jaraco> !karma dstufft

[21:19:27] <pmxbot> dstufft has 10 karmas

[23:59:22] <dstufft> jaraco: ok, merged the PR so we have the pkg_resoruces.parse_version sort order for LegacyVersion

[23:59:31] <dstufft> need to push it onto the setuptools PR still