Integrating w/ distutils, hooks?

[Terry Hancock]

Some time ago, I got the idea that I wanted to build image 
resources from vector graphic originals, instead of 
marshalling hundreds of tiny little icon images by hand.
I wrote "BuildImage" to do this for me, and so far, it
works very well, so I'm trying to make it easier to use
and available to more developers.

There is a brief (and somewhat dated) tutorial explaining 
what BuildImage itself does at:

http://www.anansispaceworks.com/Documentation/BuildImage
"""
In as few words as I can put it: "BuildImage is a build 
system for image resources." That is to say, it attempts to 
do for image resources what make does for programs.
"""

So now, I'm looking for the best way to integrate the
BuildImage package with distutils to make it the least 
painful for developers to use in their own distutils' 
packages.

And I really feel this is something I should be talking to 
distutils-sig about. This is a little long -- but the idea 
is to spark some discussion about how I ought best to do 
this:



I originally tried making my interface look more like
distutils' interface -- providing a "setup" function, etc.
I was thinking perhaps I might be able to drop in BuildImage
scripts instead of distutils scripts in image resource
sub-packages of some kind.

But the end-user is unlikely to have BuildImage
installed, and I really want 'build' and 'install'
targets of the containing distribution to go without
a hitch with or without BuildImage (assuming the images are 
already built, that is), while the developer targets 
"sdist" and "bdist" should use BuildImage to create image 
resources and include them in the distribution.  Also,
I'm probably starting to duplicate distutils functionality,
which is wasteful.

Perhaps, emulating distutils is somewhat misguided -- I 
certainly don't want to replace distutils, I just want to 
work with it in a way that will be intuitive for the 
developer.  What I really want are hooks to attach to 
within distutils.

*Ideally*, BuildImage would run at the time you would 
normally run Bison/Flex code -- i.e. it actually is a 
"pre-source" operation: you run it to complete your source 
distribution, then you compile C/C++ code, THEN you install 
Python modules, etc.  I don't really see that distutils has 
this concept as yet, but it's probably a reasonable 
compromise to run it at the same time as C/C++ builds. (?)

If that's the right path, then "sdist" should simply include 
all the necessary files for BuildImage, and the installer 
will simply need to have BuildImage installed in their 
Python site-packages in order to build the package.

If not, then maybe 'sdist' should build the images, but
certainly include all the BuildImage sources so they can
be re-built. (?)

OTOH, "bdist" should go ahead and build the images, store 
them in the correct location in the distribution tree, and 
tell distutils that it should install them along with the 
sources.  (Pretty sure of this)

Is it conventional for 'bdist' to *also* include the source
files (i.e. in an open-source built distribution)?

I'm a little confused about HOW to tell distutils what and 
where to install: it seems that I might want to use the 
"data_files" option to setup, or perhaps I want to update 
the MANIFEST or MANIFEST.in files (can I somehow get my 
code called after processing MANIFEST.in to MANIFEST so I 
can then add my additional instructions?).

Modifying "MANIFEST.in" seems a little ugly, since the idea
is that MANIFEST.in is human-edited source, while "MANIFEST"
is machine-generated.  But I don't know how I can get my
code called to work on MANIFEST *after* it has been 
generated, but *before* it is used to install files.

Currently, I visualize a typical setup.py module using 
BuildImage as something like this:

"""
# setup.py using BuildImage

import distutils
try:
    # We don't want to fail if BuildImage is not available,
    # because we are also run by the end user
    import BuildImage
    BuildImage.setup(  ... options for BuildImage ... )
except:
    print """
          You don't have BuildImage installed, so only
          distutils operations will be supported.
          """

distutils.setup(  ... options for distutils ... )
"""

So, when the end-user runs the setup script, they will see
a message warning them that BuildImage targets won't work,
but distutils will be able to do its job.  OTOH, when the
developer runs the script to build the images, that will
work too, and BuildImage will do its thing.

Obviously, though, BuildImage.setup() has to be able to tell
distutils the things it needs to know, such as what to do
with the images after they are built (typically they will be
in a resource directory under the source tree?  But in a
distribution that insists on a filesystem standard, like
Debian, they should be under /usr/share/images or perhaps
/usr/share/pixmaps, etc).

Since BuildImage won't be run at 'build' or 'install' time,
these things have to already be prepared for distutils'
installer.

But BuildImage could be made aware of the requirements for
'bdist', 'bdist_rpm', 'bdist_deb', etc., and alter what
it tells distutils accordingly.

Anyway, thanks for your time -- any recommendations would
greatly be appreciated, including references to previous 
discussion or online resources I should be reading.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com