Log file Viewer

[02:25:56] <travis-ci> pypa/pip#17503 (master - 184cca3 : Pradyun Gedam): The build was fixed.

[02:25:56] <travis-ci> Change view : https://github.com/pypa/pip/compare/9add5aa923bb...184cca345ebf

[02:25:56] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/714127194

[02:49:03] <travis-ci> pypa/pip#17504 (master - e51a027 : Pradyun Gedam): The build was fixed.

[02:49:03] <travis-ci> Change view : https://github.com/pypa/pip/compare/184cca345ebf...e51a027964b5

[02:49:03] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/714130319

[09:03:43] <agronholm> pradyunsg: what's the status on the installer? can we move forward with the wheel api?

[11:37:50] <pradyunsg> agronholm: hah, it's on my plate today -- do you have any concerns with this API: https://dpaste.org/30QE?

[11:48:00] <agronholm> pradyunsg: it does differ from my proposed wheelfile API so an adapter will be necessary

[11:50:46] <pradyunsg> I'm happy to write such an adapter in installer, if you'd prefer that. :)

[11:51:58] <pradyunsg> agronholm: the proposed wheelfile API as in https://github.com/pypa/wheel/pull/357, correct?

[11:52:31] <agronholm> yes

[11:53:32] <agronholm> my initial stance on this was that I'd like this to work directly without adapters but in the long term that might be difficult

[11:53:37] <agronholm> when both projects evolve

[11:54:12] <pradyunsg> https://github.com/pypa/wheel/blob/publicapi/src/wheel/wheelfile.py#L231 -- IIUC, we're basically guaranteed to have UTF-8 files only in dist-info (as a result of implementations).

[11:56:05] <agronholm> I'd rather not do such decoding in the wheelfile class

[11:56:22] <agronholm> it's trivial to do afterwards and might limit the uses of wheelfile

[11:57:43] <pradyunsg> regarding read_file -- dholth had said that "I think you can count on random access to the files in the .dist-info directory and encourage sequential access to the rest of the data.".

[11:58:03] <pradyunsg> https://github.com/pradyunsg/installer/issues/1#issuecomment-613986905

[11:58:47] <pradyunsg> That's basically why I went the direction of get_contents() / read_dist_info() etc.

[11:58:52] <pradyunsg> agronholm: ^

[11:59:42] <agronholm> well, all I can say that after a few rounds of comments from packaging library authors/authorities, this is what I came up with

[12:00:09] <agronholm> if you find something essential to be missing from the API, I will add it

[12:00:27] <agronholm> practical implementations should be able to point out any problems with the design

[12:03:26] <pradyunsg> If I understand correctly, dholth's comment was a result of the discussion at https://discuss.python.org/t/3810, with the intent being to be able to make minimal changes to these APIs if we make a change like that (i.e. compression for the contents of .data).

[12:04:22] <pradyunsg> I think that specific design choice comes down to how much you wanna anticipate the future and accommodate for it. ;)

[12:06:30] <agronholm> don't you think my API could accommodate compression?

[12:08:35] <pradyunsg> how would read_file work if there's an additional layer of multi-file compression (tar.gz-like) for files in .data?

[12:09:38] <agronholm> the WheelFile class would have to know about it, wouldn't it?

[12:10:13] <agronholm> right, you mean the sequential-only nature of tar files

[12:10:45] <agronholm> I have not heard of any plans to move to such a format

[12:11:26] <agronholm> the only suggested change I've heard is (zip or 7zip) inside a zip

[12:12:06] <agronholm> (which I am also against, for the record)

[12:12:59] <agronholm> LZMA support would be trivial to add to wheel, if the PyPA decides that

[12:13:21] <pradyunsg> there's certainly no plans AFAIK, but it was discussed in the aforementioned thread. :)

[12:13:42] <agronholm> yeeah...let's not cross that bridge for now

[12:13:51] <pradyunsg> fair enough! ^>^

[12:14:34] <agronholm> I feel that any deviation from the standard zip format would have to have extraordinary benefits to be seriously considered

[12:22:15] <pradyunsg> agronholm: question -- is it possible to have an empty folder get unpacked from a wheel file?

[12:23:12] <agronholm> I suppose?

[12:23:31] <agronholm> not sure

[12:23:50] <agronholm> IIRC the wheel spec does not deal with this case

[12:24:32] <agronholm> I also recall there was some discussion on this subject on either discourse or the issue tracker

[12:25:02] <pradyunsg> I recall such a discussion too -- but I can't find it.

[14:30:31] <PSFSlack> <deveshkusingh> pradyunsg: \o

[14:37:38] <pradyunsg> @devesh: o/

[15:02:06] <travis-ci> pypa/pip#17509 (master - 7e6ff08 : Pradyun Gedam): The build passed.

[15:02:06] <travis-ci> Change view : https://github.com/pypa/pip/compare/e51a027964b5...7e6ff08aae2d

[15:02:06] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/714209027

[15:13:35] <devesh> pradyusng: May I DM you? Had some questions about the triage bit.

[16:40:20] <dstufft> agronholm: pradyunsg FWIW I do want to do the compressed container inside of a zip thing at some point, I just haven't gotten the spare cycles tgo push on it yet

[16:42:38] <dstufft> whether the interior xontainer is a zip or a tarfile doesn't really matter, non sequential access to it is probably going to be slow

[16:45:50] <dstufft> just adding LZMA support to wheel file isn't nearly as good, becasuse that compression operates on a file by file basis, which eliminates a large chunk of potential compressionablity

[19:18:46] <travis-ci> pypa/pip#17510 (master - 89d8cba : Chris Hunt): The build passed.

[19:18:46] <travis-ci> Change view : https://github.com/pypa/pip/compare/7e6ff08aae2d...89d8cba55bdd

[19:18:46] <travis-ci> Build details : https://travis-ci.org/pypa/pip/builds/714262754