crossplatform py2exe - would it be useful?

[Thomas Heller]

Alex Martelli <aleax at aleax.it> writes:

> Oren Tirosh wrote:
>    ...
>>> > 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?
>> 
>> You can't import __main__ - you'll get the one already in sys.modules.
>
> If there's a __main__ in the zip, we could remove (even assuming it's
> already there) the yet-empty sys.modules['__main__'].
>
>> The code for the main script needs to be executed in __main__'s dict.

Then we name the boot module __boot__ and import this from the zip.
This could then execute the script in the __main__ module's namespace.

> So, I reiterate an idea I've already expressed: key on the executable
> file's name.  If it's at least six characters long and the first six
> characters are (case-insensitive) 'p', 'y', 't', 'h', 'o', 'n' in this
> order, forget the whole thing and proceed like now; in other words,
> use whatever new tricks we insert *if and only if* the executable file's
> name does NOT start with (case-insensitive) 'python'.
>
>> problems on some obscure environments. A possible alternative would be
>> to have a configuration area inside the executable that can be modified
>> by an external program (e.g. py2exe). The program would search for a
>> signature string and modify the section after it. The configuration
>> area can be as simple as a string that overrides the command line
>> arguments.
>
> I suspect "obscure environments" may make it hard for py2exe to find
> the needed signature and get at the 'configuration area' (depending on
> how executable files are stored when seen as stream of bytes).  Still,
> such an area would also be useful for other purposes, as you mention
> (e.g., supplying the -O switch "at compile time", and the like).  So,
> perhaps, we could simply test the executable's name FIRST, and if the
> name starts with "python" just do nothing, otherwise look at the
> configuration area (string) and so on.

Sounds much like the way py2exe already works now.  It locates the
appended zip-file by searching the exefile from the end, then finds the
beginning of the zipfile, and looks for a magic number there, which is
used to verify that the next n bytes before this position is a C
structure containing the required flags.

I don't like the idea to scan the executable for a magic signature
without further hints where this should be.

>  On any "obscure environment"
> where the set of tricks doesn't work, one would simply have to avoid
> renaming or copying the python interpreter to weird names, and otherwise
> would be just about as well or badly off as today.

>From reading the McMillan installer sources some time ago, I have the
impression that on some obscure platforms it's not possible to append
the structure and the zipfile to the executable, and on other obscure
platforms (or maybe runtime environments, maybe a cgi executable started
from apache) it may be difficult to the pathname if the exefile.

But, all in all, it sounds like a plan. Although I have the impression
that it may be difficult to convince the python-dev crowd to include
this in 2.3.1. (Is anyone of them reading this thread?)

Thomas