[Py2exe-users] py2exe plug-ins?

[Jimmy R. <ji...@re...>]

I'm looking for a little feedback here from anyone who cares to think
about this...

------------
BACKGROUND
------------

In the past Thomas has seemed reluctant to build logic into py2exe to
handle the peculiarities of various packages (e.g., matplotlib's need
for data files, gadfly's dynamic import of sql_mar.py, etc.). I was
never quite sure if I agreed with him or not. Now that I've made a
couple of releases I have much more respect for his wisdom. :)  It would
be extraordinarily difficult for someone to maintain a significant set
of popular Python modules, understand the nuances of each, and test them
with each release under multiple versions of Python (not to mention
multiple versions of the modules). It just wouldn't scale well.

At the same time, a number of users come across the same issues over and
over again (e.g., matplotlib comes up regularly on the list and py2exe
seems to come up on the matplotlib list now and again). That seems a
shame as it makes py2exe harder to use. But, the community has a great
deal of knowledge when it comes to using py2exe with various modules as
evidenced in the wiki and the support offered on this and other lists.

----------
THE IDEA
----------

The idea I'm mulling over is implementing a plug-in architecture that
would allow people who are expert in one package or another to create
plug-ins rather than (or in addition to) wiki pages. Authors of packages
could even include the plug-ins with the package itself if they choose
to. Certain plug-ins (e.g., one that knew how to leverage the
information in Python eggs) might even make their way into py2exe
itself.

---------
DETAILS
---------

Plug-ins would take the form of Python modules installed wherever the
developer and/or user deem appropriate. I'm afraid of too much magic so
my current thinking is that a plug-in would have to be explicitly
imported by the user in their setup.py. The plug-in would then need to
register itself with py2exe. It would be up to the plug-in developer
whether that is done as soon as it is imported or if the user would need
to call something to cause that to happen. So, it might suffice for the
user to write:

from distutils.core import setup
import py2exe
import matplotlib.py2exeSupport

setup(...)

On the other hand, if the plug-in needed more information, then it could
register itself when the user makes a call to supply more information:

from distutils.core import setup
import py2exe

import matplotlib.py2exeSupport
matplotlib.py2exeSupport.UseBackend('wx')

setup(...)

There are two approaches I'm considering at the moment (I'd certainly
listen to other ideas as well) for how the plug-in would interact with
py2exe. The first is to simply make a call into py2exe that looks much
like the current setup call. Any arguments supplied would be merged with
arguments from other plug-ins and the user's setup call. The other
approach is to let each plug-in (in some order to be determined later)
get the setup arguments and have a chance to modify them. The two
approaches aren't necessarily mutually exclusive - it might make sense
to implement the former using the latter. Here's an example of what the
first approach might look like...

import py2exe
py2exe.addArgs(data_files=3D[('matplotlibdata', ...)])

The second approach is a little more complicated, but allows a little
more flexibility:

import py2exe

def callback(argDict):
    data_files =3D argDict.setdefault('data_files', [])
    data_files.append(('matplotlibdata', ...))
    return argDict

py2exe.register(callback)

With the second approach it would be possible to check for settings that
are inherently incompatible with a given package - for example a plug-in
whose associated package doesn't work with single-file executables could
raise an exception if the user requests one. This might also be possible
with the first approach if the plug-in architecture detects conflicting
arguments, e.g. the plug-in could specify bundle_files=3D3 and an
exception could be raised by the architecture if the user or any other
plug-in supplies a conflicting argument.

My current desire to have interaction be at the argument level is driven
by a few things. First, new interfaces to the various settings in py2exe
aren't necessary - everything is available right away and everything
stays in sync over time. Also, the architecture would have a relatively
small interface to the rest of py2exe - it is relatively modular which
helps with maintenance. Finally, plug-in writers would have very little
to learn - their current knowledge of py2exe and a given module would be
almost everything they need to know.

--------
ISSUES
--------

There is also at least one downside. The distutils setup function would
need to be hooked in some ugly way to avoid changing the ubiquitous:

from distutils.core import setup
import py2exe

setup(...)

Hooking the setup function isn't particularly difficult, but it doesn't
feel very clean either. Another potential snag is how command line
arguments would be merged into all this - I'd prefer that plug-in
writers not have to interpret them in addition to the setup parameters
if they want to examine things.

Thanks for any feedback or ideas you may have.

Jimmy