"Go ahead, make my pep." We should make a python-dev t-shirt with this on it :) Top-posted from my Windows Phone ________________________________ From: Daniel Holth<mailto:dholth@gmail.com> Sent: 2/15/2015 9:46 To: Nick Coghlan<mailto:ncoghlan@gmail.com> Cc: Paul Moore<mailto:p.f.moore@gmail.com>; Steve Dower<mailto:Steve.Dower@microsoft.com>; Python Dev<mailto:python-dev@python.org> Subject: Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support Go ahead, make my pep. I will appreciate seeing it happen. On Feb 15, 2015 8:47 AM, "Nick Coghlan" <ncoghlan@gmail.com<mailto:ncoghlan@gmail.com>> wrote: On 15 February 2015 at 23:21, Paul Moore <p.f.moore@gmail.com<mailto:p.f.moore@gmail.com>> wrote:
On 15 February 2015 at 08:59, Nick Coghlan <ncoghlan@gmail.com<mailto:ncoghlan@gmail.com>> wrote:
The other option would to cut PEP 441 way back to *just* be about standardising and registering the file associations, and recommending the use of pip to obtain the build machinery with (whether pyzaa, pyzzer or Twitter's more comprehensive pex). It would be a short PEP, but potentially still worth it for the improved visibility of the decision when folks are trying to figure out what "pyz" and "pyzw" files are later.
Ok, thinking about this a little more.
Getting the extension support is the key thing on Windows - at the moment, people are faced with adding their own file associations or putting binary data in a .py file, neither of which is a nice choice. Tooling is important, though - sure, you can zip the data up and put a header on, but it's fiddly.
Which brings us full circle. A simple module, executable as "python -m zipapp" (see below re name) which exports a single function, pack() that creates the archive. If we want to provide a script to wrap the module, like pyvenv.py does for venv, I've no objection to that - presumably it would go in Tools/Scripts? If people (like me) want to experiment with a more programmatic API for building pyz files, they can do so on PyPI, and if such a thing becomes sufficiently mature we can look then at proposing it for inclusion in the stdlib, as an extension to the zipapp module.
Regarding naming, I'm happy to go with zipapp if it's your preference. Presumably the wrapper in Tools/Scripts would be pyzipapp.py?
Or we just skip the wrapper and make "python -m zipapp" the recommended invocation style. Adding a wrapper later is fairly easy, but removing it would be difficult.
So the usage would be something like
python -m zipapp [options] dir_to_zip
Options: -p <interpreter> The interpreter to use on the shebang line (defaulting to /usr/bin/env python) -o archive_name The name of the output file (defaulting to the source directory name with a .pyz extension) If the argument has no extension, add '.pyz' -m module:function The entry point to call (written to __main__.py) Using this is an error if there is a __main__.py, and mandatory if there isn't
If you want anything more complex, it's easy enough to write your own script based on zipfile, or use one of the modules on PyPI.
Does this sound reasonable? If it's OK, I'll go ahead and prepare an update to the PEP and an implementation. (Steve, looks like I may be learning how to maintain the wix files after all - wish me luck :-)) If I hear no objections in the next couple of days, I'll assume everyone's OK with it and I'll prepare a PEP update and a patch.
Sounds good to me. Daniel, do you mind if Paul becomes a co-author on PEP 441 and updates it as described? It seems a bit tidier than allocating a new PEP number and rejecting PEP 441, when the revised proposal is essentially just a simplified and renamed version of your original idea. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com<mailto:ncoghlan@gmail.com> | Brisbane, Australia