On Mar 31, 2013 1:09 PM, "Philippe Ombredanne" <pombredanne@nexb.com> wrote:
>
> On Sat, Mar 30, 2013 at 8:22 PM, Daniel Holth <dholth@gmail.com> wrote:
> > Python ZIP Application Support -
> > https://docs.google.com/document/d/1MKXgPzhWD5wIUpoSQX7dxmqgTZVO6l9iZZis8dnri78/edit?usp=sharing
> > PEP: 4XX
> > Title: Improving Python ZIP Application Support
> So I guess that this already-available-yet-hidden-or-little-known
> feature we had since Python 2.6 will be getting a little light.
>
> Let me ask a few silly questions:
>
> Does this means that any zip with a __main__.py is de-facto already executable?
> What about a wheel with a __main__ ? or an egg?
> Or a source archive where the __main__ calls setup.py install or
> buildout bootstrap?
> Is this something to promote?
> How is this overlapping with other packaging approaches? or possibly
> replacing them all?

Yes regardless of the extension, yes, yes, not really, doesn't overlap much.

A __main__ at the root of a wheel or egg would be a problem since it would wind up in site packages, shadowing other mains. Wheel itself uses a __main__ in a sub path of the archive. Python app.zip/subpath - that works too.

Generally if you can have an installer you don't want the zip application strategy. It is best for medium complexity scripts or pure python applications where the user just wants to use the software and not build on top of it.

We don't want packages to self-install except in special cases. It doesn't leave enough control to the end user.

> --
> Philippe Ombredanne
>
> +1 650 799 0949捤 pombredanne@nexB.com
> DejaCode Enterprise at http://www.dejacode.com
> nexB Inc. at http://www.nexb.com