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