Log file Viewer

[08:04:28] <Ivo> techtonik: in https://github.com/pypa/pip/pull/1681/files submitting commented functionality in a PR isn't exactly useful

[08:05:33] <Ivo> you need to submit a PR with *uncommented* code that actually changes behaviour that people can run, not so that they have to manually uncomment things (assuming thats what you want others to do)

[08:06:40] <Ivo> as it stands all that PR gets pip to do is also install wget

[08:08:35] <Ivo> and if its an initial feature that warrants RFC, its fine if its not perfect yet, as long as what you'ver written is an actual functional modification; its just another git branch and PR in the end that one can delete or close, respestively; tryng it out is just a matter of fetching and checking out the branch so there is no need to worry about breaking things because its all in separate branches

[08:08:58] <Ivo> I say that because I notice you're submitting things through github's web interface

[15:21:34] <dstufft> I hate everything about HTTP and Content-Encoding

[15:21:54] <Alex_Gaynor> dstufft: shoutout to who can even known if this stuff is text or bytes

[15:23:27] <dstufft> Given a .tar.gz file you will have servers that: 1) Do nothing, and serve the file without a Content-Encoding header 2) Notice it's compressed already and add a Content-Encoding: gzip header 3) Not notice (or care?) it's compressed already and compress it again and add a Content-Encoding gzip header

[15:24:11] <dstufft> Hopefully setting Accept-Encoding: identity will solve #3

[15:24:40] <dstufft> but with my luck it'll instead expose a 4th case of 4) It'll notice it's compressed already, and then you don't accept compressed responses and will decompress it before sending it to you

[15:27:46] <Alex_Gaynor> That one seems unlikely.

[15:28:33] <dstufft> hopefully

[15:40:03] <Ivo> this is obviously why we should make xz default

[16:46:48] <jezdez> dstufft: are you going to be at pycon btw?

[16:46:55] <dstufft> nope :[

[16:46:59] <jezdez> noooo :(

[16:47:08] <jezdez> asking because I'm talking with erikrose and peterbe about peep

[16:47:26] <jezdez> do you know the latest state of the requirements format 2.0 disussion?

[16:47:41] <dstufft> I don't, I think we punted on it for now?

[16:48:18] <qwcode> yea, it has no inertia from anybody atm

[16:48:23] <jezdez> oh, ok

[16:48:30] <jezdez> I think we could utilize erik for that

[16:48:42] <jezdez> that sound way to evil than intended :D

[16:48:47] <jezdez> *sounded

[16:48:58] <dstufft> I have some ideas about what I think it should look like, but it's not super high on my priority list ATM

[16:49:06] <jezdez> gotcha

[16:49:22] <jezdez> the back story is that we got the okay from mozilla sec to use peep

[16:50:23] <dstufft> cool

[16:53:35] <dstufft> I should probably write down my thoughts on securing pip installs going forward, and also requirements 2.0

[16:53:44] <dstufft> instead of keeping them in my head

[16:54:52] <qwcode> jezdez, the "lock file" discussion happened here btw https://github.com/pypa/pip/issues/1175

[16:55:03] <qwcode> erik was in that

[16:55:30] <jezdez> qwcode: ah, thanks :)

[16:55:51] <jezdez> dstufft: that'd be extremely useful

[16:56:12] <jezdez> I know I won't have time to do the heavy lifting, but I think we could with help from Erik get a PoC ready

[16:56:23] <jezdez> the important bit is to know what our stance is

[16:57:51] <qwcode> the peep thing is locking using comments in "requirments 1.0" files. is he talking about more than that...

[17:01:45] <dstufft> I'm -1 on using comments in mainline pip like peep does, so integrating peep into pip is going to rely on requirements 2.0 or some other solution that fits into requirements 1.0

[17:03:13] <jezdez> yeah, I had a feeling you would say that

[17:03:33] <jezdez> I don't think that'll bother erik though, he just wants to implement his idea

[17:03:54] <jezdez> so if we give him some way to specify a format, then he'll go with it

[17:03:58] <jezdez> e.g. yml or whatever

[17:07:24] <qwcode> the general idea is similar to Gemfile/Gemfile.lock, so if he's thinking in those terms, that's the general direction

[17:09:08] <qwcode> been working with ruby/puppet lately, so a bit more familiar with Gemfiles now

[17:09:44] <jezdez> awesome, I played with https://github.com/nvie/pip-tools/tree/future for that

[17:13:49] <qwcode> for me, there's 2 main drivers for a better requirements system: 1) locking, hash-based repeatability 2) cleaner way to add more to requirements (install options, environment markers)

[17:17:39] <dstufft> http://d.stufft.io/image/1G2b2n3y3u1i the top 4 classifiers on PyPI

[17:17:43] <dstufft> GOOD JOB TEAM

[18:13:14] <qwcode> our github irc service is still pointing to #pip, changing to #pypa-dev

[18:15:58] <qwcode> virtualenv was changed, but not pip

[21:21:28] <jezdez> qwcode: will do

[21:22:03] <qwcode> jezdez, I changed it already, so it's ok now I think

[21:23:03] <jezdez> qwcode: ah, cool thx

[21:23:18] <jezdez> it's weird, I remember changing it

[21:23:24] <jezdez> for both, I mean

[21:23:46] <jezdez> I'm on a super flaky connection here though, I wonder if the form didn't submit correctly or something

[21:24:23] <qwcode> when I changed it, we got a backlog of notifications that come in

[21:27:18] <jezdez> ah, gotcha

[21:27:27] <jezdez> oh well, thanks for catching it :)

[21:27:32] <qwcode> np

[21:27:53] <jezdez> the move seems to have gone well so far

[21:28:05] <qwcode> I like it

[21:30:50] <qwcode> jezdez, it might be worthwile to cherry pick the docs updates (for the channels) over to master branch for pip/virtualenv show it shows on "latest" docs, which comes from master

[21:31:03] <jezdez> ah, not a bad idea

[22:04:01] <travis-ci> [travis-ci] pypa/virtualenv#445 (master - 9b38338 : Jannis Leidel): The build passed.

[22:04:01] <travis-ci> [travis-ci] Change view : https://github.com/pypa/virtualenv/compare/6dc9b1d376b0...9b383381bdc8

[22:04:01] <travis-ci> [travis-ci] Build details : http://travis-ci.org/pypa/virtualenv/builds/21628951

[22:31:57] <Alex_Gaynor> dstufft: 1685 LGTM, shipit