crossplatform py2exe - would it be useful?

Kevin Cazabon kevin at cazabon.com
Wed Aug 6 23:26:14 CEST 2003


Hi Thomas;

I've tried Freeze before, but I'm hooked on py2exe because it's so
SIMPLE and flexible, and handles all the weird cases automatically...
For those of us that aren't C gurus, anything that makes the process
easier is welcome.

To clarify your proposal, would you simply build the executable using
the same setup.py script on other platforms too, or would you have to
do more manual steps?

Thanks for the great work so far... py2exe ROCKS!  q:]

Kevin.


Thomas Heller <theller at python.net> wrote in message news:<ptji8wgr.fsf at python.net>...
> I'm currently working on a new version of py2exe, which will require
> Python 2.3 and later, because it uses the zipimport mechanism.
> 
> Since py2exe is a distutils extension, and since C compilers are
> commonly available on most platforms except Windows, it would be fairly
> easy to let py2exe generate a C source file installing this import hook,
> and let distutils' C compiler build an executable file from this.
> 
> Would this be useful, or would I be wasting my time, since McMillan
> installer, cx_freeze, and tools/freeze already do it?
> 
> At the end of this post you'll find excerpts from the readme file, which
> is currently the only documentation available.
> 
> Thomas
> 
> The readme file:
> 
>   A new and improved py2exe for Python 2.3
>   ========================================
> 
>   Uses the zipimport mechanism, so it requires Python 2.3 or later.  The
>   zipimport mechanism is able to handle the early imports of the
>   warnings and also the encodings module which is done by Python.
> 
>   Creates a single directory, which must be deployed completely.
> 
>   (Most of this is based on ideas of Mark Hammond:) Can create any
>   number of console and gui executables in this directory, plus
>   optionally a windows service exe, plus optionally an exe and dll com
>   server.  The com servers can expose one or more com object classes.
> 
>   All pure Python files are contained in a single zip archive, which is
>   shared by all the executables.  The zip archive may also be used by
>   programs embedding Python.  Since extension modules cannot be imported
>   from zipfiles, a simple pure Python loader is included in the zipfile
>   which loads the extension from the file system (without requiring that
>   the directory is in sys.path).
> 
>   It would be nice if the executables could be run with only a single
>   sys.path entry containing the absolute filename of the zipfile, but it
>   seems for dll com servers the executable's directory is also
>   needed. The absolute filenames are constructed at runtime from the
>   directory containing the executable, and the zipfile name specified at
>   build time.
> 
>   The way has changed how build targets are specified in the setup
>   script. py2exe installs it own Distribution subclass, which enables
>   additional keyword arguments to the setup function:
> 
>   console = [...] # list of scripts to convert into console executables
>   windows = [...] # list of scripts to convert into gui executables
>   com_servers = [...] # list of fully qualified class names to build into the exe com server
>   service = [...] # list of fully qualified class names to build into a service executable
>   zipfile = "xxx.zip" # filename of the zipfile containing the pure Python modules
> 
>   All of the above arguments are optional. The zipfile name defaults to
>   'library.zip'.




More information about the Python-list mailing list