[Python-Dev] PEP 441 - Improving Python ZIP Application Support (original) (raw)
Paul Moore p.f.moore at gmail.com
Sat Feb 14 15:44:14 CET 2015
- Previous message: [Python-Dev] Building on Windows - importlib.h changed
- Next message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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).
- 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.
- 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
- Previous message: [Python-Dev] Building on Windows - importlib.h changed
- Next message: [Python-Dev] PEP 441 - Improving Python ZIP Application Support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]