Log file Viewer

[00:51:05] <sigmavirus24> dstufft: btw, I started digging into that pip --root bug in setuptools... I can't figure out wtf is happening there =P

[00:51:15] <sigmavirus24> I found some logic there last night that just made me laugh and cry at the same time

[00:51:21] <dstufft> sounds like pip

[00:51:26] <dstufft> what's the --root bug

[00:51:27] <dstufft> I forget

[00:51:28] <sigmavirus24> it was setuptools actually

[00:51:34] <sigmavirus24> let me find the bug

[00:51:40] <sigmavirus24> gh3029

[00:51:44] <sigmavirus24> https://github.com/pypa/pip/issues/3029

[00:51:59] <sigmavirus24> We just pass it to setuptools so I'm thinking setuptools is the reason why we're not installing that in the new root

[00:52:21] <sigmavirus24> It's very reproducible though

[00:52:49] <dstufft> sigmavirus24: we might actually control that

[00:52:54] <dstufft> I'm not sure

[00:53:02] <dstufft> we have like 3 different "install" code paths

[00:53:12] <dstufft> hoping to move things so we only ever install from wheels at some point

[00:54:15] <sigmavirus24> dang

[00:54:28] <sigmavirus24> the only one dealing with --root was in req/req_install.py

[00:54:32] <sigmavirus24> (or the only one I found)

[00:54:38] <sigmavirus24> so I worked based off of that

[00:55:55] <dstufft> sigmavirus24: yea, it's "complicated"

[00:56:17] <dstufft> RELEVANT TWEET : https://twitter.com/pumpichank/status/633406854727643140

[00:56:23] <dstufft> I should just put that in the /topic

[00:56:30] <sigmavirus24> Sounds right

[03:03:12] <lifeless> dstufft: my resolver branch makes install a lot better

[03:03:21] <lifeless> dstufft: but yeah

[06:13:57] <tchaypo> dstufft: your resolver makes it a rube goldberg machine that may run forever

[08:20:09] <xafer> First direct commit went well \o/ - and a tricky one with that

[08:49:50] <lifeless> xafer: you just got core? congrats

[08:50:09] <xafer> thanks :)

[08:53:00] <lifeless> tchaypo: did you mean lifeless before ?

[08:54:11] <tchaypo> Umm

[08:54:13] <tchaypo> Yes

[08:54:20] <tchaypo> That's embarrassing

[09:42:45] <ronny> lifeless: btw, any plans to resore the pre-auto-wheel style download behaviour?

[09:54:52] <lifeless> ronny: none that I know of

[10:26:24] <ronny> lifeless: that makes bascially all my current deployment scenarios worse with pip 7+

[13:30:42] <sigmavirus24> dstufft: so I just did `pip install requests; pip install requests[security]` on pip 7.x and it works as expected so there's no need for a bug =P

[13:30:52] <sigmavirus24> That user last night must have been using an old version of requests

[13:31:02] <sigmavirus24> *old version of pip

[18:14:20] <lifeless> ronny: so a) I'm not pip core, just a contributor. b) There's a bug open for a download command, as you know, and c) pip is contributor driven AFAICT so its what folk step up to do that matters and

[18:15:12] <lifeless> d) pip wheel is probably the right thing to use these days anyway, *because* of the existing platform specificity of env markers any 'download' is already platform dependent

[18:32:23] <ronny> lifeless: d) nah, because linux sucks there is bascially only sdists and universal wheels ^^

[18:35:47] <ronny> lifeless: but yeah, a,b,c put a dent into my hope that you could help directly with that, im sadly a bit too stripped of time to deal with it correctly

[21:05:24] <xafer> hello dstufft, I dont get the point of https://github.com/pypa/pip/pull/3041/files ?

[21:05:47] <xafer> _vendor does not seem to have been updated ?

[21:06:22] <dstufft> xafer: I'm going to be cutting a release and I just bump the releases whenever I do. For setuptools all of the changes in that version were in easy_install.py or setuptools so there were no changes to the parts we added, and there doesn't appear to be any changes to ipaddress either

[21:06:29] <dstufft> so I jsut bumped the versions

[21:06:44] <xafer> oh ok ^^

[21:48:52] <dstufft> lifeless: why is pbr putting a pbr.json in pip

[22:02:14] <lifeless> dstufft: its a bug

[22:02:31] <lifeless> dstufft: https://bugs.launchpad.net/pbr/+bug/1483067

[22:02:34] <lifeless> dstufft: marked critical

[22:02:45] <dstufft> lifeless: unacceptable, I demand software to be perfect

[22:02:49] <dstufft> lifeless: Ok!

[22:02:53] <lifeless> dstufft: and, as soon as Nakato or tchaypo come up for air, I plan to point them at it and say 'interested?'

[22:03:08] <dstufft> It's not causing any problems that I know of, I just happened to notice it and was confused

[22:03:53] <tchaypo> Could someone add a note to that bug describing what the expected behaviour is?

[22:04:11] <dstufft> Not putting a pbr.json in every sdist just because pbr is installed

[22:04:16] <lifeless> but tchaypo is underwater becoming a manager

[22:04:25] <tchaypo> no, i’m underwater with jury duty

[22:04:27] <dstufft> sounds unpleasent

[22:04:33] <tchaypo> i don’t have time to be underwater becoming a manager

[22:04:54] <dstufft> somehow I became a defacto project mananger

[22:04:56] <tchaypo> same net result, but I sit in a different room

[22:04:58] <lifeless> tchaypo: so yeah, that next :)

[22:05:01] <dstufft> I am not amused by this result

[22:05:05] <lifeless> dstufft: which project?

[22:05:15] <dstufft> lifeless: PyPI

[22:05:21] <dstufft> and I guess pip too

[22:05:23] <dstufft> maybe

[22:05:34] <tchaypo> so the expected behaviour is “pbr should not be adding files into the .egg-info directory”?

[22:05:46] <tchaypo> There’s no need to be storing that information anywhere else, we just need to stop writing it there?

[22:05:52] <dstufft> tchaypo: not unless the project in question uses pbr

[22:05:57] <dstufft> the problem is it's adding it to pip

[22:05:59] <dstufft> and pip doesn't use pbr

[22:06:04] <lifeless> tchaypo: I've added a comment

[22:06:13] <dstufft> I jsut happened to have pbr installed

[22:06:19] <tchaypo> ah

[22:06:21] <tchaypo> geesh

[22:06:27] <tchaypo> bad pbr *spank*