pmxbot IRC Log Viewer

[15:49:21] <Theuni2> EWDurbin: hey

[15:49:50] <EWDurbin> Theuni2: hola

[15:51:15] <Theuni2> got some time to review the pull request for bandersnatch with me?

[15:51:22] <Theuni2> i've got a few questions

[15:52:09] <EWDurbin> Sure thing, lemme grab my laptop

[15:52:14] <Theuni2> jup

[15:52:15] <EWDurbin> Catch you in 5

[15:52:17] <Theuni2> ack

[15:57:00] <EWDurbin> Theuni2: have keyboard, will talk

[18:50:19] <qwcode> dstufft, did you add the wheel-version thing to 1.5.3? I don't understand the motivation for that right now?

[18:51:11] <dstufft> qwcode: yes I did

[18:51:50] <dstufft> qwcode: because not doing it violates the Wheel spec, and it means that pip 1.5 will possibly break in weierd ways if Wheel 2.0 does something backwards incompat

[18:53:20] <qwcode> dstufft, ok, you working on wheel 2.0? and have stronger confidence that it's coming soonish?

[18:54:08] <tomprince> pip versions live in the wild for a *long* time.

[18:54:08] <dstufft> qwcode: I have a Wheel 2.0 spec started yes, but even if it doesn't come soon we don't want old pips to do the wrong thing even if it comes 10 years from now

[18:54:37] <dstufft> a loud error is way better than ilently doing the wrong thing

[18:54:49] <dstufft> silently*

[18:55:33] <qwcode> dstufft, roger that

[18:56:08] <dstufft> I'd prefer it if the Wheel is incompatible it falls back to sdist, but that's more than I feel comfortable putting into a patch release

[18:56:13] <dstufft> i'd like to do that in 1.6 tho

[19:00:11] <qwcode> wheel 2.0, and not wheel 1.1? big changes?

[19:00:36] <dstufft> the changes aren't massive, but they are techincally backwards incompatible

[19:04:14] <qwcode> dstufft, thoughts on whether 'pip wheel --rebuild' (i.e no rebuild by default) qualifies for 1.5.3? I know it's annoying

[19:05:07] <tomprince> Huh. I assumed it didn't rebuild by default, since my wheel dir is also in my index path.

[19:05:19] <dstufft> qwcode: I'm on the fence, on one hand I think not rebuilding by default is saner, but it's also a new feature

[19:06:21] <qwcode> tomprince, yes, that's true in that case, but not true otherwise.

[19:07:17] <qwcode> dstufft, don't know if you saw my comments, but it's semi-hard to fix, because we're not in charge of the filename

[19:09:53] <dstufft> qwcode: if it's hard to fix then I say we wait to 1.6

[19:10:15] <dstufft> hard to fix means more likely to have wierd edge cases and breakage

[19:11:36] <dstufft> till*

[19:11:43] <qwcode> dstufft, the diff would likely by small, but it involves using distutils command classes, so it's awkward, and I'm not quite sure how to do it yet.

[19:12:53] <dstufft> Ok, well I think it probably makes sense to wait. It's not going to break anything to rebuild, it'll just do extra work then is needed right?

[19:13:16] <qwcode> dstufft, it might be better to make a change in bdist_wheel to have it own the logic, and surface flags for pip

[19:15:32] <qwcode> yes, it's the behavior now to always rebuild. I can mention adding your wheel dir to your index path, to prevent rebuilding as a "trick" I guess in the docs

[19:18:02] <dstufft> qwcode: makes sense

[19:18:10] <dstufft> we can make it better in 1.6

[19:18:23] <qwcode> dstufft, not sure how familiar you are with 'pip wheel', but fundamentally, it's just like 'pip install', but calls 'bdist_wheel' instead of 'install'

[19:18:39] <dstufft> not super familar

[19:18:48] <dstufft> I understand it's concept and such

[19:19:01] <dstufft> I kinda want to refactor to seperate things out cleaner

[19:20:04] <tomprince> I use it all the time, for building dependencies locally, or for a homogenous deployment environment.

[19:21:17] <qwcode> dstufft, pip install and pip wheel share the massive 'prepare_files' step. that seems correct to me. the big refactor that's needed in IMO involves properly breaking up 'prepare_files' and all that entails

[19:21:34] <dstufft> yea

[19:21:59] <dstufft> there's also some changes I want to make with how we discover things

[19:22:13] <dstufft> right now we treat each file as a seperate thing to install, and order based on that

[19:22:29] <dstufft> what i'd like to do is create an object for each version, that knows all of the files that can satisfy that version

[19:22:42] <dstufft> so we'd have say a "1.5.3" version object, that knows there is an sdist and a Wheel

[19:23:00] <dstufft> so we can pass that object around, try the Wheel, and if that fails fall back to the sdist

[19:26:38] <qwcode> dstufft, yea, that makes sense. also, the priority sorting in index.py is a jumble.

[19:27:40] <qwcode> I don't think --find-links has priority over the default index in all cases. I keep meaning to look at that

[19:29:58] <qwcode> dstufft, did you have any reaction to my wheel cache PR? https://github.com/pypa/pip/pull/1572

[19:30:35] <dstufft> qwcode: didn't get a cahnce to look yet

[19:31:08] <dstufft> I've got kidney stones so I'm kinda in pain + on narcotics so I'm mostly trying to focus on getting 1.5.3 done

[19:31:28] <qwcode> dstufft, sorry dude

[19:33:12] <dstufft> qwcode: no worries, just don't want y'all to think i'm ignoring things :)

[19:34:11] <qwcode> dstufft, no worries, just know that I intentionally avoided adding more logic to big methods like prepare_files. really, it wasn't that big of a change. we had all the pieces basically already.

[19:43:06] <qwcode> dstufft, wow, the bandersnatch security hole is fixed now. that was quick

[19:44:24] <dstufft> qwcode: that is thank to EWDurbin

[19:44:49] <qwcode> yea, I saw, that guy is everywhere now

[19:45:02] <qwcode> thanks EWDurbin

[19:46:43] <EWDurbin> qwcode: no problem! xmlrpc2 was a great way to facto out a bunch of stupid 2.6 compat stuff too

[19:47:01] <EWDurbin> that i put into bandersnatch

[19:47:02] <EWDurbin> :-p

[22:49:39] <Ivo> qwcode: you have any preference for using email.parser.Parser over my current code path?

[22:50:23] <dstufft> if it matches what other projects are doing then I have a preference

[22:51:16] <qwcode> yes, I prefer email.parser, vs creating regex patterns

[22:51:27] <Ivo> I kanged it from how pkg_resources was finding .distinfo information

[22:52:47] <qwcode> Ivo, what? pkg_resources use email.parser for metadata

[22:53:12] <Ivo> oh.. well at least, finding the file

[23:01:15] <Ivo> should a wheel only ever have one .dist-info directory?

[23:01:34] <qwcode> yes

[23:01:36] <Ivo> like, it couldn't contain more than one package..

[23:01:49] <qwcode> one wheel, one package

[23:02:20] <Ivo> sweet

[23:05:31] <Ivo> qwcode: did you misunderstand the meaning of the feature when you posted the first comment?

[23:06:46] <Ivo> qwcode: https://github.com/Ivoz/pip/blob/5f40562e0f333d39ca75f357a596251e5788b2d5/pip/wheel.py#L406 look better?

[23:08:14] <Ivo> hmmm... if wheel 2.0 used 7z or xz, how would you tell the difference between it and a 1.0 wheel?

[23:08:45] <Ivo> or even if wheel 1.2 allowed bzip and xz, for arguments sake

[23:09:11] <Ivo> just do a loop trying to open them as different formats?

[23:09:17] <dstufft> don't know at this point

[23:09:24] <dstufft> maybe we can't ever make Wheel anything but a zip file

[23:09:31] <qwcode> Ivo, yes, ignore my first comment.

[23:10:00] <Ivo> xz woulda been kewl

[23:10:10] <dstufft> I mean if we really wanted xz, we could use a ZIP_STORED instead of ZIP_DEFLATE so that zip files don't do any compression, and just put an xz file as a payload inside of a Wheel container

[23:10:24] <dstufft> and have the metadata still in the zip container

[23:10:29] <Ivo> that's a neat idea

[23:11:10] <dstufft> I'm not super worried about it though, xz isn't available except in Python 3.something

[23:11:29] <dstufft> and our file sizes tend to be small enough not to matter much

[23:11:33] <Ivo> I was imagining having a future wheel format that only worked on python 3... ^_^

[23:11:44] <dstufft> that would be a long way down the road :)

[23:11:52] <Ivo> virtualenv is 2.8mb

[23:11:57] <dstufft> anyways, I gotta go for a bit

[23:12:17] <qwcode> Ivo, seems we can replace the listdir loop, since we know what format to expect for dist-info dirnames

[23:12:18] <Ivo> catch

[23:12:49] <Ivo> qwcode: I was having trouble managing an easy way to deducde the package name and version

[23:13:23] <qwcode> Ivo, yea, I gotta run atm too. comment later.

Log file Viewer

Help | Karma | Search:

#pypa logs for Sunday the 16th of February, 2014