Go ahead, make my pep. I will appreciate seeing it happen. On Feb 15, 2015 8:47 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote:
> On 15 February 2015 at 23:21, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 15 February 2015 at 08:59, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
