[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
True.
> 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.
Regards,
Vinay Sajip
More information about the Distutils-SIG
mailing list