Log file Viewer

[17:38:00] <dstufft> jaraco: ping

[17:38:08] <jaraco> pong dstufft

[17:39:18] <dstufft> jaraco: I know we talked about it before, but I forget what the outcome was, how did we decide to handle PEP 440 in setuptools? something makes me think it was just copy/pasting the regexes from the packaging lib into pkg_resources and modifying the APIs to use them... but I may be wrong

[17:39:38] <jaraco> I don't think we talked about a specific implementation.

[17:39:53] <jaraco> I haven't put much thought into the specific implementation, but I'm happy to review pull requests.

[17:40:59] <dstufft> ok

[17:41:06] <dstufft> I'll take a look and see what's easiest then

[17:49:07] <jaraco> thanks dstufft - most appreciated

[21:01:52] <dstufft> jaraco: I forget, do you accept PRs on github for setuptools?

[21:01:55] <dstufft> or is it only bitbucket

[21:02:43] <jaraco> dstufft: I slightly prefer bitbucket because it keeps the history in one place. Github is nicer for travis integration. I'll accept a PR on either.

[21:03:03] <jaraco> For you, use whatever's easiest for you.

[21:03:10] <dstufft> ok, I'll probably do github then because everytime I use hg I end up getting frustrated :D

[21:03:23] <dstufft> thanks!

[21:03:26] <jaraco> welcome

[22:43:35] <dstufft> jaraco: wow, this specifier implementation is confusing :|

[22:43:51] <dstufft> some sort of state machine

[22:44:29] <jaraco> The one in pkg_resources?

[22:44:32] <dstufft> yea

[22:44:59] <dstufft> If I grok it correctly, I don't think it's actually powerful enough to handle everything in PEP 440

[22:45:06] <dstufft> so I'll have to fix that

[22:46:39] <jaraco> I haven't touched much of that.

[22:46:58] <dstufft> jaraco: understandable

[22:47:09] <jaraco> Is the plan to adapt the current implementation to match pep440? Why not have pkg_resources use a reference implementation entirely?

[22:49:54] <dstufft> jaraco: so the main reason is that the api that pkg_resources provides is "lower level" (in a way) than packaging, int hat pkg_resources.parse_version returns the compare key, whereas packaging has a Version class... if you're OK with it returning classes instead of tuples I can totally do that though

[22:50:07] <dstufft> or well I suppose I could return the internal sort key

[22:50:13] <dstufft> that the class in packaging uses

[22:50:19] <dstufft> Version()._cmp_key

[22:51:08] <jaraco> Does Version implement __iter__ ?

[22:51:35] <jaraco> If it did, then it could be a drop-in replacement for a tuple.

[22:52:01] <jaraco> And if __iter__ returns _cmp_key, and if _cmp_key items are strings, then that would be completely compatible with parse_version.

[22:53:40] <dstufft> it does not implement __iter__, the API it provides is mostly opaque in that you give it a version, and it treats itself as the reprenstation of that version, you can turn it back into a string, or compare them, or get the public or local part of the version, or test if it's a pre-release

[22:55:33] <jaraco> Is _cmp_key a tuple of strings, similar to the result of parse_version?

[22:56:42] <dstufft> it's a tuple of integers, other tuples (which can contain integers or strings), and a special Infinity/NegativeInfinity objects

[22:57:55] <jaraco> Are Versions sortable against each other (i.e. implement __lt__)?

[22:57:57] <dstufft> yes

[22:58:29] <jaraco> In that case, it's suitable to just return a Version.

[22:59:02] <dstufft> ok

[22:59:03] <jaraco> It's more important that packaging tools start using the same structures.

[23:01:08] <dstufft> there's one other part in this all, Version can only handle things which are parseable as PEP 440 versions, historically parse_version would parse _anything_, Version only handles PEP 440, there is LegacyVersion which handles anything, but you cannot compare a Version and a LegacyVersion at the moment - Though perhaps that should change so the LegacyVersion is always considered < Version

[23:01:44] <dstufft> instead of being an error

[23:02:30] <dstufft> oh wait, no I lied, LegacyVersion can only be compared for equality, not for < or >

[23:02:47] <dstufft> (this is for things like "dog", where we can't really define a sane sort)

[23:03:04] <jaraco> I think it's okay to only handle Versions.

[23:03:24] <dstufft> ok

[23:03:37] <dstufft> the specifiers do contain an escape hatch for things that aren't valid PEP 440 versions

[23:03:45] <dstufft> so this isn't throwing away everything

[23:03:51] <dstufft> e.g. you can do ``===dog``

[23:03:59] <dstufft> but not ``==dog``

[23:04:02] <dstufft> or anything like that

[23:04:40] <jaraco> Does pypi use pkg_resources?

[23:05:28] <jaraco> That is, by deprecating broken versions, do we break those packages in indexes where they're hosted?

[23:08:35] <dstufft> it does, but I'll be modifying it to use packaging itself too

[23:09:26] <jaraco> I guess I worry about other indexes like devpi or chishop - if they rely on pkg_resources and can no longer host packages, that might be a problem.

[23:10:05] <jaraco> It's still probably okay.

[23:10:32] <jaraco> We just might have to revisit to add back compatibility, depending on what use-cases emerge.

[23:10:38] <dstufft> yea

[23:11:06] <dstufft> could do something like parse_version -> (0, LegacyVersion()) or (1, Version())

[23:11:20] <dstufft> so that parse_version will still be sortable

[23:11:46] <dstufft> and have setuptools itself move away from parse_version and towards just using packaging itself

[23:11:54] <dstufft> e.g. leave parse_version as a shim

[23:12:35] <jaraco> nice

[23:12:52] <jaraco> !rubberstamp

[23:12:52] <pmxbot> Bad credit? No credit? Slow credit? APPROVED!