crossplatform py2exe - would it be useful?

[Alex Martelli]

Thomas Heller wrote:
   ...
>> 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.

I guess it might, yes.


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

Python 2.3 now supports building a .so (or whatever) on many systems,
needing just a switch on ./configure.  If one chooses to go for a
static build anyway, sure, one will have to link statically.  But
no recompile and relink would be needed (unless 'pythonm' is something
I don't know about rather than just a typo for 'python'...?).  E.g.,
on Linux:

$ cat main.py
print "Hello world"
$ python -c 'import main'
Hello world
$ zip main main.pyc
  adding: main.pyc (deflated 31%)
$ cp /usr/local/bin/python2.3 ./myapp
$ cat main.zip >>myapp
$ ./myapp -c 'import sys; sys.path.insert(0,"myapp"); import main'
Hello world
$

So, if I could just insert that "-c string" into myapp in some
way -- and have myapp, which is just a copy of the python 2.3
interpreter, execute it in some way instead of the arguments
[leaving the arguments to use for sys.argv] -- I'd be in clover,
quite indifferently as to whether myapp is statically OR
dynamically linked.  Admittedly at this level it doesn't work
with __main__, as Oren suggested ('import __main__' is a noop
unless one deletes sys.modules['__main__'], and if one does it's
"ImportError: Cannot re-init internal module __main__").  Which
is why I've reverted to 'main' without underscores;-).

Anyway, the zipfile would of course be prepared in much more
sophisticated (but presumably platform independent?) ways, and
the suitable string (including e.g. a -O or whatever) could be
inserted (by a py2exe tool or the like) into a suitable config
area in the executable, as Oren suggested.



>>> 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.  But it COULD easily be encoded in a "configuration area".

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

Oh yes, it surely would need 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,

Perhaps this step could be left to a separate tool (basically we're talking
about a self-unpackaging zipfile, it seems to me).

> 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?

For example, a shell script cannot be set-userid (it wouldn't be secure).


Alex