Py2Exe, lessons from use...

[Thomas Heller]

"Mike C. Fletcher" <mcfletch at home.com> wrote in message news:mailman.990695801.20305.python-list at python.org...
> Disclaimer:
> The following is written very late at night, assume there are errors and
> omissions. There is no guarantee, implicit or explicit that the methods
> described below are, in any way, reliable, useful, or intelligible.  Use at
> your own risk.
>
> I have recently been experimenting with Py2EXE for packaging up a rather
> large application including:
[...]
>
> Python Imaging Library
>
> The python imaging library requires a number of plug-ins to be of any use.
> Here's a simplified main script which seems to work for a simple PIL-based
> application...
>
> import thumbnail
> import ArgImagePlugin, BmpImagePlugin, CurImagePlugin, DcxImagePlugin,
> EpsImagePlugin,\
[...lot of other modules snipped]
>
> Where thumbnail is a simple script importing Image.  As you can see,
> specifying all of those plug-ins on the command line would be somewhat
> annoying.

(py2exe does not find the plugins because they are imported with
__import__, but you already knew this.)
You can create a setup.cfg file and list the modules in this way:

--- setup.cfg file ---
[py2exe]
includes=ArgImagePlugin,BmpImagePlugin,CurImagePlugin,DcxImagePlugin,...
--- EOF ---

Due to a bug in py2exe, the whole list must be ON ONE LINE, and there
must not be any whitespace. I will fix this in the next release.

>  I have not been able to figure out how to stop Py2EXE from
> finding the TK and TCL directories using the above imports.  I just excluded
> the tcl directory in my .tar command for packaging the application.  There's
> probably a better approach.

The '-e Tkinter' command line switch should have done the trick.

>
>
> win32com
> Basically, using the latest CVS version of py2exe, I specified a command
> line argument -i win32com.gen_py.* which attempts to include all of the
> modules in the gen_py directory.  During operation of the program, a new
> gen_py directory will be created and the generated modules will be saved
> there.  I spent some time trying to figure out what was going on when I got
> errors reporting that an integer could not be properly converted when
> loading from the gen_py directory.  Eventually I modified my distribution
> archive to prevent the gen_py directory from being included, this seemed to
> solve the problem, though I never did track down the reason it occurred.
> Bottom line, don't include the gen_py directory in your distributions.  With
> the activexwrapper included, this seemed to allow for proper operation.

I will look into this. It is currently not really satisfying.

>
>
> General comments:
> The "command line" focus for the system is difficult to work with when
> creating large applications.  I wound up creating batch files to automate
> the publishing process, and including all of the dependencies into my main
> script, which slows down startup time somewhat.
> I would really prefer to specify the files for scanning within the setup
> module, leaving the command line for "end-user" options.  Using setup.cfg as
> mentioned in the documentation didn't seem to work, I didn't have time to
> track down why not.
See above.

But wait: It is possible to enable additional keyword parameters for the
setup-function by using a custom Distribution class. Importing py2exe
could replace distutil's standard Distribution class by an extended one,
but is this really the way to go...

> There needs to be a mechanism for differentiating critical and trivial
> output while running distutils commands. A mode that printed (only) those
> files actually copied into the archive and those copied to the destination
> directory would be useful.  Similarly, one which suppresses the "X not
> copied to directory y, source yada, yada" warnings so that build failures
> and files actually copied can be seen would be useful.

This is normal distutils behaviour, and as such difficult to change from py2exe.

>
>
> Py2EXE is very useful (as was the McMillan installer which I was using for
> previous projects), allowing executable python applications makes using
> python in the workplace possible (I tried getting a colleague to set up his
> machine for this application as a set of python modules, he ran into some
> weird win 32 COM error, we never did get it fixed).  Thanks to all involved.
>
> Enjoy yourselves,
> Mike

Thanks again for the extensive review, Mike. This is the kind of
feedback which will (hopefully) improve this little utility.

Thomas