[Python-Dev] Fwd: Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

On 24 February 2015 at 19:23, Daniel Holth <dholth at gmail.com> wrote:
>> I'd specify that when the output argument is a file open for writing, it is
>> the caller's responsibility to close the file.  Also, can the file be a
>> pipe?  (I.e. are we using seek()/tell() or not?)  And what about the input
>> archive?  Can that be a file open for reading?
>
> It seems like the very next thing I would want after trying pack()
> would be to pass a callback that returns True iff a file should be
> included in the archive. After that I might just want a ZipFile
> subclass or a regular ZipFile to which I could add my own files?
> "return ZipFile with shebang already filled in". It's hard for me to
> say where the boundary between the convenience API and re-implementing
> this simple thing yourself if you have complex needs should be.

Yes, it's a slippery slope.

The whole API is a pretty thin wrapper over a ZipFile object. I'd
rather keep it to the most basic requirements, and defer anything even
slightly complicated to the ZipFile API. The one exception is the
set_interpreter/get_interpreter APIs, which are messy to do with
ZipFile, and a pain to do "by hand" (because working with part-text,
part-binary files is just naturally messy).

It would be possible to write up how easy it is to create a pyz file
by hand using the zipfile module, but doing so would (IMO) lose the
nice simple message of this PEP - "use zipapp to bundle your code into
an app that's supported all the way back to Python 2.6".

Paul