[Python-Dev] PEP 441 - Improving Python ZIP Application Support

[Paul Moore]

I'm looking at putting together a patch for CPython to implement PEP
441. In doing so, there are a few issues that I'd like to raise with
the PEP. These are all to do with the supporting app "pyzaa" (IIRC,
Nick proposed renaming this to "pyzapp", which I like, but it's not a
big deal either way).

1. The PEP says that the application will warn if you try to add C
extensions to the archive. In practice, this will be quite hard to do
- extensions vary across platforms, and it's not only C extensions
that won't work from an archive (consider a DLL with a pure-python
ctypes wrapper). We could check the filenames for "known" extensions
(maybe using importlib.machinery.EXTENSION_SUFFIXES, but that varies
by platform) but I think that's going to be fragile. IMO, the costs
aren't worth the benefits, and I'd like to remove this proposal and
simply document that applications packed up with pyzaa need to be
tested to ensure they work from a zipfile.

2. The option to compile Python source seems to me to be of limited
use. It ties the archive to a particular Python version (more
precisely, only one version gets the benefits of precompiled
bytecode). It's also tricky to implement, particularly the option to
compile an existing archive, because there standard library py_compile
and compileall modules work on the filesystem, and for compiling files
in an archive it would be better to build the bytecode in memory (no
need to use tempfiles). I'd prefer to say that if users want to
include bytecode, they can precompile on disk (using compileall) for
as many versions as they want.

FWIW, Daniel's standalone pyzaa program doesn't currently include
either of the above features.

As well as removing things, I'd like to add a programmable API for the
utility. At the moment I only have a rough idea of how that would
work, but I'm thinking of a PyZApp class, which can be created from a
filename or an open stream (like a ZipFile object) and which has
methods to set the shebang line, setting the main entry point, and
adding files or directories. Does that need to go into the PEP or is
it OK to review the API as part of the patch? I don't mind either way,
but my normal coding process tends to be to fiddle with the API as I
code it up and use it in the main app, so I'd normally leave
documenting the final API till it's written...

If the above seems like a reasonable plan, I'll work up a patch with
the intention that it gets approved and implemented in time for 3.5.

Paul