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

[Daniel Holth]

Go ahead, make my pep.

I will appreciate seeing it happen.
On Feb 15, 2015 8:47 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

> On 15 February 2015 at 23:21, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 15 February 2015 at 08:59, Nick Coghlan <ncoghlan at 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 at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150215/4d5e70fb/attachment-0001.html>