[Distutils] How to handle launcher script importability?

Vinay Sajip vinay_sajip at yahoo.co.uk
Wed Aug 14 15:58:59 CEST 2013


> Better suggestion: just append a PEP 441 .pyz to the .exe, and no

IIUC PEP 441 is about tooling to create archives; don't we just need a Python-compatible .zip (i.e. with a __main__.py)?

> For bonus points, you can actually stick a compatibly-built wheel on
> the end of the .exe instead, and embed the entire relevant project.
> ;-)

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?

> Writing the script.py file means the current user needs write access
> to a program installation directory, which is probably not a good


> idea.  Also, what if two instances are running, or you overwrite an
> existing script while it's being read by Python in another process?

That could probably be taken care of with a bit of footwork.

> No, if you're taking the embedding route, it's got to be either a
> zipfile, or else you have to use -c and give Python an offset to seek
> to in the file.

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?

> (As for ctypes, if that's needed for this approach (which I somewhat
> doubt), there are official Windows binaries available for 2.3 and
> 2.4.)

It's needed only if you use the specific approach I used - which was to use the Windows UpdateResource API to embed the script as a pukka Windows resource. Of course, if you're just appending something to the .exe, you don't need ctypes.


Vinay Sajip

More information about the Distutils-SIG mailing list