Bill Janssen
3/21/2010 11:53:00 PM
Martin v. Löwis <martin@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