(original) (raw)

On Feb 15, 2015 8:47 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:

On 15 February 2015 at 23:21, Paul Moore <p.f.moore@gmail.com> wrote:
\> On 15 February 2015 at 08:59, Nick Coghlan <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 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 | Brisbane, Australia