[Distutils] How to handle launcher script importability?

[PJ Eby]

On Wed, Aug 14, 2013 at 7:34 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> Jason R. Coombs <jaraco <at> jaraco.com> writes:
>
>> This means that instead of installing, for example:
>>
>>   Scripts\my-command.exe
>>   Scripts\my-command-script.py
>>   Scripts\my-command.exe.manifest
>>
>
> Just to muddy the waters a little, I'd like to suggest an alternative
> approach which doesn't appear to have been tried:
>
> 1. The installer just installs foo.exe on Windows for script 'foo',
>    where the foo.exe contains the actual script 'foo' as a resource.
>
> 2. The launcher, before looking for foo-script.py, examines its resources.
>    If a script resource is found, it is extracted and written to
>    foo-script.py in the same directory as foo.exe. If such a resource isn't
>    found, it continues to the next step.
>
> 3. The launcher looks for 'foo-script.py' in its directory, invokes it and
>    waits for it to complete.
>
> 4. If a 'foo-script.py' was written in step 2, it is deleted.
>
> The launcher comes with an embedded manifest, so no external manifest is
> needed.

Better suggestion: just append a PEP 441 .pyz to the .exe, and no
extraction is necessary; the .exe just reads out the #! part.  For
Python 2.6 and up, the .exe can simply pass itself as argv[1] to the
interpreter.  (For older Pythons, a little -c and PYTHONPATH munging
is required, but should be doable.)

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


> Thoughts?

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?

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.

In any case, it'd probably be a good idea to offer some command line
tools for manipulating such .exes, to e.g. show/change what Python
it's set to use, extract/dump/replace the zip, etc.

(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.)