PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 22nd of February, 2016

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[00:46:59] <StevenK> dstufft: I know it's Sunday, but if you're still around, I have a fairly urgent packaging PR to unbreak setuptools
[00:56:34] <dstufft> StevenK: whats up
[00:56:58] <StevenK> dstufft: https://github.com/pypa/packaging/pull/62 and https://bitbucket.org/pypa/setuptools/issues/499/version-202-doesnt-like-non-numeric
[01:10:38] <dstufft> StevenK: commented on the PR
[01:14:04] <StevenK> dstufft: Tests fail if PEP440 was first -- it's a nuance of the parser, it wants things that can match more widely first
[01:14:46] <StevenK> dstufft: lifeless and I hit something similar when I was working on it during the sprint
[01:20:18] <dstufft> mkay
[01:22:17] <StevenK> dstufft: Can I impose for a release too?
[01:26:55] <dstufft> StevenK: done
[01:28:48] <dstufft> I'm going to lay down now, ttyl
[01:29:39] <StevenK> dstufft: Thanks!
[01:30:06] <lifeless> StevenK: do we need to up0date the PEP too ?
[01:31:11] <StevenK> lifeless: The PEP only mentions PEP 440 rules
[01:53:49] <lifeless> StevenK: sure; just the PEP has the grammar in it? DId you not change the grammar?
[01:53:54] <lifeless> StevenK: (I haven't read your patch)
[01:56:00] <StevenK> -VERSION_ONE = VERSION_PEP440 | VERSION_LEGACY
[01:56:00] <StevenK> +VERSION_ONE = VERSION_LEGACY | VERSION_PEP440
[01:56:25] <lifeless> does that match the PEP ? or... packaging handles non-pep440 stuff still?
[01:56:33] <StevenK> The latter
[02:01:48] <lifeless> ah kk
[02:54:21] <StevenK> Turns out 16.3 now breaks 'name (==4)' from parsing
[03:02:59] <StevenK> lifeless: When you're around, I could use your help
[08:25:55] <lifeless> StevenK: was driving; hi
[08:26:36] <StevenK> lifeless: Hi. I'm having more problems with pyparsing WRT parsing out versions, do you have time to look?
[08:29:08] <lifeless> StevenK: I can help; I'm in a social context right now, so expect a little latency as we do it.
[08:30:47] <StevenK> lifeless: Starting with packaging 16.3, it will parse both PEP 440 compliant specifiers and legacy ones. However, it no longer accepts "name (==4)" as a valid requirement.
[08:31:24] <StevenK> lifeless: Based on my playing around, I can get the grammar to either parse the above requirement, or requirements involving legacy versions, but not both.
[08:44:11] <lifeless> ok
[08:44:34] <lifeless> so (==4) is valid for pep-440 not legacy right?
[08:44:44] <lifeless> what was the legacy version that broke and started this cascade?
[08:45:52] <StevenK> ==4 is PEP 440, the grammar is supposed to accept either PEP 440 or legacy with or without brackets
[08:46:32] <StevenK> name==1.0.org1 is the requirement that kicked off this mess
[08:48:52] <lifeless> ok, so legacy can't be first - you have to have the narrow things first
[08:49:31] <lifeless> is ) valid in a legacy version specifier ?
[08:50:49] <StevenK> They are, but the parens are included in the grammar two levels above VERSION_ONE
[08:51:10] <lifeless> so I think (==4) is failing
[08:51:15] <StevenK> I've got VERSION_ONE set back to VERSION_PEP440 | VERSION_LEGACY
[08:51:16] <lifeless> because legavy specifier is eating the )
[08:51:32] <lifeless> also
[08:51:54] <lifeless> remember that legacy specifiers are a superset of pep-440, so if we want the structure etc, we need to have pep440 first
[08:53:33] <StevenK> Blah, adding ) to the LegacySpecifier regex gets the test passing
[08:53:59] <StevenK> However, legacy versions still fail with VERSION_PEP440 | VERSION_LEGACY
[08:54:15] <lifeless> hmm adding it? I don't think thats right
[08:54:53] <StevenK> ?P<version>[^;\s]* was the version part of LegacySpecifier
[08:55:13] <StevenK> I added ; in 16.3 so that it could deal with markers
[08:55:37] <lifeless> but markers can't apply to legacy specifiers can they ?
[08:55:49] <StevenK> Why can't they?
[08:56:19] <StevenK> The grammar doesn't forbid it, and PEP 508 does not even mention non PEP 440 specifiers
[08:56:33] <StevenK> And we should be liberal with what we accept
[08:56:59] <lifeless> well, not if its going to make our lives hell
[08:57:40] <lifeless> yeah, you *can't* have ; in the version
[08:57:45] <StevenK> The regex was [^\s]*, I don't think [^;)\s]* is too terrible
[08:57:52] <lifeless> its fatal
[08:59:52] <lifeless> its because you end up with
[09:00:19] <lifeless> V="1.0;marker"
[09:00:22] <lifeless> rather than
[09:00:26] <lifeless> V="1.0"
[09:00:30] <lifeless> marker="marker"
[09:00:58] <StevenK> So adding ; to the LegacySpecifier regex was the right move?
[09:01:14] <lifeless> adding ; causes the problem I'm describing above
[09:01:17] <lifeless> it makes it ambiguous
[09:01:33] <lifeless> if markers are going to apply to legacy versions, they hve to do so through the rest of the grammar
[09:01:57] <StevenK> I have a test with a legacy version with a marker, and it behaves as expected
[09:02:19] <lifeless> whats the test?
[09:02:39] <StevenK> And I'm not in fact adding ;, [^;] is *excluding* it
[09:02:57] <lifeless> oh, ok so yes. tired :)(
[09:03:05] <lifeless> excluding ; and ) are good things IMO
[09:03:19] <StevenK> Long drive, I see
[09:03:20] <StevenK> :-)
[09:03:30] <StevenK> Surely the car did all the work :-P
[09:03:50] <lifeless> still - on the road from 10 to 6:30
[09:03:55] <lifeless> with a 2.5hr charge gap
[09:04:15] <StevenK> Did you use autopilot at all?
[09:04:55] <lifeless> oh yeah, massively
[09:04:59] <lifeless> but you can't ignore the road
[09:05:26] <lifeless> since the tesla needs to be told 'tesla, you're drunk, go home' a couple times an hour
[09:05:33] <StevenK> Haha
[09:05:43] <lifeless> so on the grammar
[09:05:52] <lifeless> basically we need to poke at that regex to make sure its not ambiguous
[09:06:25] <lifeless> brain fail for me right now, but have a look up the layers looking for other things that the rest of the grammar would loook for that aren't allowed in pep-440, and make sure they are also excluded
[09:06:30] <StevenK> VERSION_ONE = VERSION_PEP440 | VERSION_LEGACY doesn't actually deal, which is sad.
[09:07:09] <StevenK> VERSION_ONE = VERSION_PEP440 ^ VERSION_LEGACY *does*, but that works by computing them both and picking whichever one matched more characters.
[09:07:30] <StevenK> And choosing the left one, in the case that they both matched the same
[09:07:49] <lifeless> hm | doesn't deal? how so
[09:08:59] <StevenK> With VERSION_PEP440 | VERSION_LEGACY, 2 test failures, output of one is InvalidRequirement: Invalid requirement, parse error at "'.org1'"
[09:10:45] <lifeless> so that says to me that VERSION_PEP440 parsed up to the .org1 successfully
[09:11:09] <StevenK> Which would be correct
[09:11:20] <StevenK> Since ==1.0 is valid PEP 440
[09:11:33] <lifeless> so I think we need to teach PEP440 that a valid version followed by a . should not be accepted
[09:11:39] <lifeless> e.g. we need to make it a little more greedy
[09:11:40] <StevenK> So maybe ^ (which is Or) is the correct answer
[09:11:54] <lifeless> or perhaps yes
[09:11:58] <StevenK> | being MatchFirst
[09:12:13] <lifeless> ^ sounds reasonable
[09:12:28] <StevenK> "MatchFirst expressions are matched left-to-right, and the first match found will skip all later expressions within"
[09:12:55] <StevenK> So maybe even a partial match is enough to skip VERSION_LEGACY
[09:13:31] <lifeless> it will be
[09:13:41] <StevenK> Right, then ^ it is
[09:13:49] <StevenK> Since we want the possibility for both
[09:15:34] <StevenK> lifeless: I will push this up, and condense the above mess into the PR
[09:15:51] <StevenK> lifeless: You should go and stare at a wall, or perhaps sleep
[09:23:19] <lifeless> cool; shall do
[09:34:02] <Ivo> god in what computing world does ^ mean OR
[10:36:25] <StevenK> Ivo: pyparsing author's choice. There was a reason, not that I agree with it.
[11:01:16] <dstufft> MatchFirst is (generally) better than Or in pyparsing because it's more performant, but obviously you need Or sometimes
[12:07:36] <jaraco> @ronny: How's it going with the Github migration for Setuptools?
[14:33:19] <xafer> @dstufft any news from RTD regarding pypa.io ?
[14:36:48] <dstufft> No
[14:36:52] <dstufft> let me poke them again
[17:38:54] <rZ_> hi all, i have two PRs open for pip and they haven't had any comments for a few weeks, travis passes on both, what's up with them? https://github.com/pypa/pip/pull/3411 https://github.com/pypa/pip/pull/3357
[17:45:01] <rZ_> cc dstufft Ivo
[17:48:08] <rZ_> if i'm not here anymore when you have a response comment on one of the prs
[17:52:02] <Ivo> rZ_: not truly my area of expertise, I don't run OS X sorry
[17:52:56] <rZ_> no worries, but did you see the comment here https://github.com/pypa/pip/pull/3411#discussion_r51127863
[20:30:53] <lifeless> dstufft: we only need Or because of retaining legacy support
[20:31:03] <lifeless> dstufft: (and legacy being so broadly specified)
[20:31:52] <dstufft> yea
[20:32:20] <dstufft> I was just suggesitng why | would be MatchFirst instead of Or
[21:47:26] <njs> I think I have a patch for https://github.com/pypa/pip/issues/3486 -- any pip developers able to help me figure out how to write a test?
[21:53:56] <njs> (CC dstufft)