crossplatform py2exe - would it be useful?

Alex Martelli aleax at
Thu Aug 7 23:04:47 CEST 2003

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
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 >>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 (,

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


More information about the Python-list mailing list