[Distutils] How to handle launcher script importability?

PJ Eby pje at telecommunity.com
Wed Aug 14 19:29:08 CEST 2013


On Wed, Aug 14, 2013 at 9:58 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> IIUC PEP 441 is about tooling to create archives; don't we just need a Python-compatible .zip (i.e. with a __main__.py)?

I meant that it has a #! line before the zip part, so that the
launcher knows what Python to invoke.

There are also some challenges for older Pythons to invoke __main__,
since the normal Python import machinery frowns on reloading __main__.
 I expect the zip would need an extra __main.py stub to bootstrap the
loading of __main__, and then invoke python with something like '-c
"__import__('sys').path[0:0]=['/path/to','path/to/exe''];
__import__('__main').go()"'.

(It can't have the import run the app as a side effect, because
otherwise the import lock will be held, leading to Bad Things in
multi-threaded apps.)


> This is less helpful; one might have N scripts per project, no need to stick the whole project in with each one, or am I misunderstanding?

I just meant that for cases where there's only one script, or where
you are doing a custom-built application.  This also becomes The One
Obvious Way to do py2exe-like things.


> How would such an offset be used? Are you saying the -c scriptlet would use that offset to extract the script? Or do you mean something else?

Extract the script by seeking to the offset and reading it.  It's far
from ideal, though; the .zip is much better since everything back to
2.3 can support it in some fashion.


More information about the Distutils-SIG mailing list