[00:06:41] <qwcode> lifeless, ok, so "pip install --no-install -d" in your branch now unpacks and downloads, whereas before, it just downloaded
[00:06:59] <lifeless> qwcode: yeah, which AFAICT was actually a regression from earlier
[00:07:40] <qwcode> lifeless, it's hard to make sense of what combining those options should do, but the change seems ok to me.
[00:07:46] <lifeless> qwcode: I discovered this when tracking down the failure to install from my implicit wheels branch, which was due to the temporary source dir not being deleted.
[00:15:58] <lifeless> so https://github.com/pypa/pip/pull/2618 should be good to go now, I've just shuffled things a little so one more build is going to be needed
[00:43:11] <lifeless> yay - https://github.com/pypa/pip/pull/2618 is green.
[00:43:24] <lifeless> (And I have confidence that it should be green now :))
[00:49:06] <dstufft> lifeless: sorry was taking a nap, sounds like you got it sorted?
[00:55:43] <lifeless> dstufft: yeah its all ready to review and merge
[00:57:39] <dstufft> lifeless: awesome, I might cut a release before merging it just to get the topo sort out and a few other things out there before a release that holds this
[01:02:05] <lifeless> I don't want to install numpy 15 times if there are 14 things I'm installing all of which setup-requires numpy
[01:02:27] <lifeless> I want to install it once and use it 14 times, then install it into the final target once
[01:03:22] <dstufft> I had previously thought about making it so that there was a single setup requires tmp dir, than did shit like /tmp/numpy-X.Y, and /tmp/pbr-X.Y, and it would short circuit additional setup uses to add /tmp/numpy-X.Y if it was already temp installed to that location
[01:05:37] <lifeless> I want to be able to clean it up afterwards
[01:06:06] <lifeless> future iterations: I want to be able to utilise the already installed requirements
[01:06:53] <lifeless> future iterations: I want to be able to use this when running egg-info to calculate deps, for cases where install-requirements does require turing complete blah.
[01:07:08] <lifeless> initial implementation static data only, of course, because sanity
[01:07:29] <lifeless> this seems separate to req-set to me
[01:07:42] <lifeless> it needs to be able to hold multiple numpy-X and numpy-Y versions, for instance.
[01:19:00] <dstufft> lifeless: they can do IO yea, our definition of unit is a little wrong, it's really more like "does this create a virtualenv and need to invoke hte CLI and thus is it really slow" or "is it fastish"
[01:19:18] <lifeless> I don't subscribe to the 'unit === no IO' but I know others do
[01:21:56] <dstufft> lifeless: if you have a moment to look at https://github.com/pypa/pip/pull/2636, it looks right to me but since you're more familar with the refactors to this i'd love a double check
[01:23:44] <lifeless> the comment in the compat file is confusing
[01:23:49] <lifeless> should 'not' be considered installed ?
[01:24:51] <dstufft> lifeless: the list of stdlib packages was originally there in order to filter out standard library things that look like they are isntalled
[01:25:10] <dstufft> e.g. on some platforms argparse shows up in pip list natively, so that list is there to let us filter it out
[01:25:47] <lifeless> could this break things that use Requires(argparse > x.y) ?
[01:27:07] <dstufft> it just won't install argparse if they do that, Pytho puts the standard library before the site-packages, though I suppose it could break something if someone was doing some hacks to try and explicitly get argparse from site-packages
[01:29:22] <dstufft> maybe not worth the risk for an edge case
[01:30:11] <lifeless> I dunno. I have a suggestion on the code on the review for you
[01:34:35] <dstufft> lifeless: thanks, updated with your changes
[07:28:40] <dstufft> lifeless: https://github.com/pypa/pip/pull/2641 removed some of the crap that you noticed that was duplications :)
[09:45:23] <lifeless> dstufft: cool; uhm, I hope you merged my branch first :)
[13:21:37] <dstufft> lifeless: Ok, I've got to lay down for a bit. I've messed around with the wheel building PR a bit. I rebased it onto develop (which exposed a few issues with the PR), then i pulled out a few of the more indepenent commits and merged them on their own so that the diff itself of this PR is smaller and easier to read. You can see it at https://github.com/pypa/pip/pull/2649. I've commented there with the issues that I'm aware of now. If you want
[13:21:37] <dstufft> to continue working on it you can take my branch (or redo it if you want) and go from there
[21:06:56] <xafer> hello dstufft, could you restart the broken builds on https://travis-ci.org/pypa/pip/builds/57544212 ?
[21:44:31] <dstufft> lifeless: updated the ticket with some information, feel free to take it back. I just wanted to play with it and start to review it. I identified some issues in my PR that I noticed while doing that
[21:45:44] <xafer> dstufft, any chance for a 6.1.2 with https://github.com/pypa/pip/pull/2659 in a near future ?
[21:49:48] <dstufft> xafer: did this break with 6.1.0 but work with 6.0.x?
[21:50:53] <xafer> dstufft, it worked on 6.0.8 yes
[21:50:56] <dstufft> lifeless: I probably just didn't notice.
[21:51:13] <dstufft> if the rebase didn't conflict I didn't touch it
[21:51:48] <lifeless> dstufft: this is likely another cause of failures
[21:52:06] <lifeless> dstufft: I'm redoing the rebase with your branch as a reference, so that my internal state is synced :)
[21:52:31] <dstufft> lifeless: other than pulling out the isolated-ish changes I tried to only make changes that were needed to cleanly apply. It's possible (maybe even likely!) that I didn't do it completely correct
[21:52:42] <dstufft> oh and I added a changelog entry
[21:52:51] <dstufft> feel free to toss my work or whatever makes the most sense to you
[21:55:30] <lifeless> dstufft: good to get some of the primitives merged
[21:56:33] <xafer> sure, no problem, it's just to know if I should patch our sytem (certainly pin pip to 6.0.8) or if I should just wait for the fix to land :)