using Python distutils bdist_msi to create installer for large complicated package

[Bill Janssen]

Martin v. Löwis <martin at v.loewis.de> wrote:

> > I've been re-thinking the UpLib Windows installer technology, and it
> > occurred to me to wonder why I can't just use the nice bdist_msi module
> > in Python to build my packages.  I took a look, and it seems almost
> > doable.  Presumably you wrote it?
> 
> Correct.
> 
> > UpLib is a big package, with lots of Python and Java and C programs, and
> > for Windows I package it with lots of other programs like those from
> > xpdf.  All of this is installed in C:\Program Files\UpLib\VERSION\, in
> > bin, lib, share, and so forth subdirectories.  If I autogenerated a
> > setup.py file which described everything as "data_files", it should be
> > simple to package everything up in a Cab, and bdist_msi apparently also
> > provides the ability to add pre- and post-install scripts.  Everything
> > I need, really.
> > 
> > There are a couple of Python-specific options in the code: the "Product
> > Name" is prefixed with the python version, and in the GUI, the default
> > location is the location of a Python distro.  If the package had a
> > "--non-python" option which would defeat these, and perhaps also set
> > "no-target-optimize" and "no-target-compile" to True, it would be a
> > simple but pretty general-purpose packager module.
> 
> I'd rather recommend to base this off msilib directly, instead of trying
> to subvert bdist_msi to do what you want.

Yes, that was the first thing I looked at.  But as you've pointed out in
the past, it requires a lot of MSI know-how to use that library
directly.  For a variety of applications, you've already embedded most
if not all of that know-how in the bdist_msi class.  And subclassing
is the indicated way to build on distutils, isn't it?

> There is actually quite a lot python-specifics in bdist_msi.

Well, sort of.  If a setup only references "data_files" -- no Python
packages, no extensions -- it's pretty generic.

The "add_find_python" method seems the most python-specific.  I'd
remove a lot of that in the generic case.  And, of course, modify "run"
so that the product name isn't prefixed with "Python x.y".

> If you find this too tedious to use,
> please propose *base classes* that could become part of msilib, rather
> than trying to create *subclasses* of the bdist_msi classes.

Yes, good idea.  For example, all those panels that are in get_ui
could be added by a InstallerBaseGUI class of some sort.

But still, just a few mods to bdist_msi could go a long way.  For
instance, you've already pulled out "get_installer_filename". I'd add a
similar method, "get_product_name", which would typically just return
the user-specific name, but in the default case could prefix the product
name with Python 2.6.

Bill