pmxbot IRC Log Viewer

[00:16:04] <StevenK> lifeless: pong

[00:57:43] <lifeless> StevenK: so this bug

[00:57:54] <lifeless> StevenK: did my brain-state dump last night make sense?

[01:10:00] <StevenK> lifeless: I'm still not sure what you mean by translated back

[01:10:21] <lifeless> ok so

[01:10:34] <lifeless> extras_require = {'foo': ['bar']}

[01:10:46] <lifeless> that gets translated into the METADATA file as

[01:11:00] <lifeless> bar; extra='foo'

[01:11:07] <StevenK> == but yes

[01:11:44] <lifeless> so so when we evaluate that, we have to know the context of the extra that we're evaluating it for

[01:12:12] <lifeless> concrete example, say I have a dependency from package p to q[e1,e2]

[01:13:43] <lifeless> we have to evaluate that twice

[01:13:51] <lifeless> in that we read in the egg info for q

[01:13:59] <lifeless> and then we evaluate once with extra=e1

[01:14:04] <lifeless> and once with extra=e2

[01:14:45] <lifeless> and union the results

[01:15:26] <lifeless> if we're trying to reconstruct the extras lines, we'd need to translate extra='foo' into {'foo': ...}

[01:15:37] <lifeless> but I don't think thats quite what we're trying to do

[01:16:15] <StevenK> No, the dependencies already seem to be worked out inside WorkingSet

[01:16:50] <lifeless> so - you *cannot* evaluate a requirement from a METADATA without supplying the extra('', or some string)

[01:17:01] <StevenK> So maybe we don't want to evaluate the marker if the variable is extra

[01:17:07] <lifeless> but you can always evaluate requirements from any other source

[01:19:16] <lifeless> oh nice

[01:19:16] <lifeless> summary: Replace code with readme redirecting to Github

[01:19:23] <lifeless> wondering wtf everything was

[01:19:59] <StevenK> I even told you I did that :-)

[01:20:14] <lifeless> didn't realise it had happened

[01:21:14] <StevenK> Migrating the code was easy, and Jason had already figured out how to do it. Migrating the issues was the difficult thing, which I worked on.

[01:23:21] <lifeless> congrats

[01:26:16] <lifeless> StevenK: do you have a working reproducer test ?

[01:29:32] <StevenK> lifeless: Not yet, but I think I understand how it fits together

[01:29:41] <lifeless> StevenK: so how is the container on line 799 constructed?

[01:29:53] <lifeless> StevenK: clearly we have in it something from a METADATA file

[01:32:17] <lifeless> so what you need to do is pass req.extras into evaluate

[01:32:21] <StevenK> I think that's already done by the time we hit WorkingSet.resolve

[01:32:38] <StevenK> Which will be blank for that req

[01:32:53] <lifeless> line 837

[01:33:27] <lifeless> shows that req.extras has a value

[01:34:07] <lifeless> The question is - is it the extras that were selected for the req - and I think it is

[01:34:15] <lifeless> its not what it exports, its what we're choosing to consume

[01:34:39] <lifeless> so, someth8ng like

[01:34:59] <lifeless> evaluate(dict(extra='fred'))

[01:35:07] <lifeless> but you need to loop over all the chosen extras

[01:35:11] <StevenK> For the if req.marker line, we are tripping over foo;extra=='ssl' and req.extra will be set([])

[01:35:21] <lifeless> and use an empty string and a 1-length list

[01:35:31] <lifeless> StevenK: sure

[01:35:41] <lifeless> here, let me sketch with code

[01:42:16] <lifeless> StevenK: https://github.com/rbtcollins/setuptools

[01:44:20] <StevenK> Those will all evaluate to false, since req.extras will be the empty set

[01:44:44] <lifeless> yes

[01:45:01] <lifeless> but when someone comsumes the extra

[01:45:09] <lifeless> req.extras should be not the empty set

[01:45:16] <lifeless> no ?

[01:45:47] <lifeless> its entirely possible that we've uncovered a long standing bug where resolve ignored extras

[01:45:57] <lifeless> since there was clearly no test around it :)

[01:46:29] <StevenK> twisted[ssl] has no marker, but pyopenssl;extra=='ssl' does, but when we get to pyopenssl, we don't know about twisted[ssl]

[01:47:30] <lifeless> StevenK: uhm

[01:48:01] <lifeless> StevenK: requires_extra in twisted is {'ssl': ['pyopenssl']}

[01:48:02] <lifeless> StevenK: ?

[01:50:27] <StevenK> tls, sorry, but same same

[01:50:39] <lifeless> StevenK: so we are evaluating the translated line from that

[01:50:43] <StevenK> lifeless: https://twistedmatrix.com/trac/browser/trunk/twisted/python/dist.py#L72

[01:50:45] <lifeless> its not actually pyopenssl yet

[01:51:00] <lifeless> the path has to be

[01:51:42] <lifeless> twisted[ssl] <- thats a req

[01:52:08] <lifeless> so the way pyopenssl's thing gets in th elist

[01:52:28] <lifeless> is the loop under #Register the new requirements needed by req

[01:53:02] <lifeless> we need to capture somewhere the fact that we're adding the pyopenssl requirement because of the 'ssl' from twisted

[01:53:19] <lifeless> I suggest a new _ prefixed member variable, or a lookaside dict

[01:54:33] <lifeless> e.g. note the extras's we consuming *from this requirement', but the extras that have caused us to consider it

[01:55:09] <lifeless> assuming I understand it correctly

[01:55:22] <lifeless> you need two packages

[01:55:25] <StevenK> foobar[baz] requires quux and we try to resolve foobar[baz]

[01:55:28] <lifeless> yes

[01:55:47] <StevenK> And both foobar and quux should be in the resultant WorkingSet

[01:55:47] <lifeless> and foobar[baz] should be installed, so you're consuming its data from a METADATA source

[01:56:07] <lifeless> you also need a test of multiple extras

[01:56:11] <lifeless> and a test of none

[01:56:24] <StevenK> I already have a test of no extras

[01:56:41] <lifeless> so resolve 'foobar' and foobar[baz] exists and references quux, but we end up with just foobar in thw ws ?

[01:56:43] <StevenK> Oh, I get it. foobar[baz] exists, but we depend on foobar

[01:56:51] <lifeless> yup

[01:56:55] <lifeless> and thw multiple case

[01:57:00] <lifeless> foobar[baz] -> quux

[01:57:10] <lifeless> foobar[zuul] -> fred

[01:57:30] <lifeless> resolve foobar[baz,zuul] -> (foobar, quux, fred) is the workingset

[01:58:07] <StevenK> Do you think foobar[baz] -> quux ; barfoo[baz] -> blah where we require foobar[baz] and barfoo is a reasonable test too?

[01:58:20] <StevenK> IE, blah shouldn't hit the ws

[01:58:39] <lifeless> StevenK: sure, barfoo's extras should not get involved

[01:58:50] <StevenK> Oh, yeah

[01:59:04] <StevenK> req.extras will be set([]) for barfoo, right

[01:59:15] <StevenK> So pointless as a test

[02:08:21] <StevenK> a

[02:09:39] <lifeless> b ?

[02:13:42] <lifeless> StevenK: pushed an updated sketch

[02:15:50] <StevenK> Currently trying to write a test

[02:16:16] <StevenK> And tripping over ValueError: invalid version number '20.6.5.post20160330' when I run python setup.py test

[17:48:51] <transit> Is there any preference for rebase vs merge when syncing the changes in the develop branch with a pull request branch?

[17:49:23] <transit> (pip)

[17:51:52] <dstufft> transit: I tend to rebase, there's no rules or project wide preference though

[17:52:24] <transit> Ok, thanks.

[17:53:54] <transit> How do pull requests usually get attention? Is there anything I should be doing to bring a healthy pull request that fixes an issue to the maintainers' attention?

[17:56:20] <dstufft> transit: which pull request is that?

[17:56:44] <transit> 3210

[17:56:52] <transit> https://github.com/pypa/pip/pull/3210

[18:05:58] <transit> Xavier said it would need a second maintainer's attention before being included in the upstream.

[18:09:26] <dstufft> transit: ok, I'll take a look in a few

[18:09:38] <transit> Thanks, appreciate it.

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Friday the 1st of April, 2016