[22:24:18] <xafer> hello, just a quick reminder of https://github.com/pypa/pip/pull/2659 :) Any plans/thoughts about a 6.1.2 ?
[22:28:52] <dstufft> xafer: sorry, I've been feeling sick the last few days so I'm not operating at full capacity
[22:31:57] <lifeless> dstufft: Oh ugh, sorry to be pestering you :(. FWIW 2659 looked sane to me
[22:32:00] <xafer> oh sorry to hear that, but no problem, there is no urgency, I was just making sure it isnt left out if a patch version is released :)
[22:32:20] <lifeless> dstufft: (as a 6.1.2 component and as something for develop)
[22:32:58] <dstufft> will merge once the tests pass on the job I just restarted that failed
[22:34:30] <dstufft> lifeless: it's no worries. just spending more time in the bathroom then the computer :V
[22:34:57] <lifeless> dstufft: you need a laptop :>
[23:27:11] <lifeless> dstufft: if you're up to it, lets talk autobuild wheels
[23:28:23] <lifeless> dstufft: also https://github.com/pypa/pip/pull/2665 can be merged (if you're ok with it :))
[23:30:58] <lifeless> dstufft: AIUI you're worried that if we build wheels for e.g. file paths that they will be stale and cause the wrong thing to be installed
[23:32:08] <dstufft> lifeless: So, part of the concern was with the --find-links thing, I haven't looked at the updated PR yet to know if it's mitigated in another way, but for instance, with the state of the PR I reviewed, pip install . in the pip directory would get a pip 7.0.0.dev0 wheel built in the find-links
[23:32:37] <dstufft> which would "leak" into the set of things that could be installed for every subsequent command
[23:33:20] <lifeless> but it will only be found if package finder *separately* finds an sdist with the same filename (pip-7.0.0.0.dev0.tgz or whatever)
[23:34:44] <dstufft> primarily I'm concerned with changes of behavior, particularly between multiple invocations of pip (other than ones related to the fact that we're building wheels which is different then isntalling straight from sdist)
[23:35:23] <lifeless> the specific code is https://github.com/rbtcollins/pip/commit/5b978b691891a99225ecc42262f50ac69ecf29d3#diff-2695f32c4432acd141c3dbe7e7e3a6b0L41
[23:35:37] <dstufft> pretending for a minute that every single thing will work 100% fine being installed from a wheel, then the goal would be to make the fact that there is a wheel cache as transparent as possible and not introduce wierdness from it being enabled
[23:37:26] <lifeless> so that when its set, it triggers that lookup
[23:37:32] <lifeless> no change to the finding-of-links code
[23:37:56] <lifeless> so the specific assumption is that 'filename
[23:38:18] <lifeless> is a good unique key to find possible wheels
[23:41:11] <lifeless> thinking about it, I think we should reject anything that doesn't look like an sdist - e.g. if its local and not a file, or if its remote and doesn't have version info
[23:42:41] <lifeless> [I presume there's a handy regex around somewhere already :))]
[23:55:18] <lifeless> dstufft: I don't understand the sorting thing - we're going to be building all the wheels the same, right ?
[23:55:31] <lifeless> dstufft: when would we produce compatible-but-less-desirable wheels?
[23:59:28] <dstufft> lifeless: it's basically a hedge against a possible "less than desireable" error case, right now if you have a wheel that has an optional c extension that you just omit on PyPy in your setup.py you'll get a pure python wheel if you build it on PyPy but a compiled wheel if you build it on CPython
[23:59:42] <dstufft> even with sorting, if you build it on PyPy first you won't get the compiled wheel ever