crossplatform py2exe - would it be useful?

[Thomas Heller]

Alex Martelli <aleax at aleax.it> writes:

> Thomas Heller wrote:
>
>> Alex Martelli <aleax at aleax.it> writes:
>> 
>>> Thomas Heller wrote:
>>>    ...
>>>>>> myscript -c "import sys; sys.path.insert(0, sys.executable); import
>>>>>> foo"
>>>    ...
>>>>> Sounds like a good idea to me, if a sensible name is chosen for the
>>>>> "main module" (I propose 'main':-).
>>>> 
>>>> My choice would have been __main__ :-) Is it really the correct way to
>>>> 'import __main__' instead of 'running' it?
>>>
>>> Well, most main scripts ARE coded with the "if __name__=='__main__':"
>>> convention, after all, so an "import __main__" can be seen as a way
>>> to just piggyback on that existing convention rather than inventing a
>>> new one in addition.  So, I concede it's better than "import main".
>>>
>> 
>> How would the hook be triggered? The zipimporter code would probably add
>> argv[0] to sys.path, and then try to 'import __main__' or something like
>> this. The problem is that a standalone executable python would have to
>> disable the standard Python command line flags and environment
>> variables, but they are parse *before* Py_Initialize() is called.
>
> Ah, yes, good point.  So, the executable needs to know whether to do
> the usual commandline and environment processing, or not, _before_
> calling Py_Inizialize.

Exactly. And it may even be useful to do specail command line
processing, an PY2EXEVERBOSE flag might be useful.

>  One approach might be to trigger this based
> on the executable's own *name* -- do the full commandline and environment
> processing if and only if the executable's name starts with (case-
> insensitive, probably, to be safe...) the six letters 'python', but
> not otherwise.  There are, no doubt, other alternative ways, too, but
> this one seems dirt-simple and practically sufficient.

On windows, where the interpreter is in a dll, providing a custom
equivalent to python.exe (as py2exe currently does) is pretty simple.
On systems where the interpreter is staically linked, there's no other
choice than to recompile and relink the whole pythonm if I understand
correctly.

>> And I hope that the options set by the command line flags and env vars
>> should now come from the __main__ script itself.
>
> I'm not sure I understand what you mean.  Anyway, I do see that if
> my 'foobar.exe' is a python.exe + appended zipfile, then running
> 'foobar -i' should just put '-i' in sys.argv[1], and NOT gobble it up
> to mean "enter interactive mode", for example.

You understood. Yes, the command line flags must be passed into
sys.argv. But I still want to set the optimize flag and the unbuffered
flag at *build* time. I'm quite sure all this cannot be encoded into the
filename.

Right now, py2exe embeds a struct containing a magic value plus these
flags into the exe, just before the zip-archive, but all this unpacking
has to be done from C code (because these flags are not writable from
Python code), so all this has to be part of the hook.

Thomas

PS: Since py2exe, even on Linux, doesn't really create a single file
executable, there are always some shared libs needed, maybe the first
step would be to create a directory containing the interpreter
executable with an appended ziparchive, the shared libs needed (zlib.so,
maybe more), and a bash script containing something like this (you'll
probably see how rusty my *nix skills are nowadays):

#!/bin/sh
exec python_with_zip -c "<<EOF
the script itself
"
EOF


What are the disadvantages of a shell-script against an (elf) executable?