Martin v. Löwis <mar...@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 -- http://mail.python.org/mailman/listinfo/python-list