Steven Bethard <steven.beth...@gmail.com> added the comment: Ok, so here's what needs to happen to make this work. Note that all of the following needs to happen at *runtime*, not at the time at which the .msi is created:
(1) Find all sub-keys of SOFTWARE\Python\PythonCore in the registry. These are the versions, e.g. 2.5, 2.6, 3.0, etc. (2) For each version, get the Python installation dir from SOFTWARE\Python\PythonCore\%(version)s\InstallPath (3) Populate the ListView table with entries containing these installation paths, e.g. something like: TARGETDIR 1 C:\Python24 TARGETDIR 2 C:\Python25 ... (4) Modify Control/SelectDirectoryDlg so that it uses a ListView (filled with the above values) instead of a DirectoryCombo. (5) Make a couple minor edits to bdist_msi.py to stop it from inserting the version into the .msi name for Python-only modules. I looked into a couple ways of doing this. Ideally, we should avoid using a CustomAction, which would require maintaining some additional C or VBScript code, and instead do everything through the database tables that are built into all .msi files. Some problems I've run into with this approach: * The only way to read the registry AFAICT is through the RegLocator table: http://msdn.microsoft.com/en-us/library/aa371171(VS.85).aspx. But RegLocator can only look up single key values, and cannot look up the sub-keys under a key (which is what we need to get the Python versions). * We could hard code all the possible versions, and stick all the corresponding SOFTWARE\...\%(version)s\InstallPath keys into RegLocator. Then these can be read into properties using the AppSearch table (http://msdn.microsoft.com/en-us/library/aa371559(VS.85).aspx), and we could then fill in the ListView table with the install paths. But AFAICT, there is no way to keep from putting one row into the ListView table for each version of Python we statically define. Which means a bunch of inappropriate rows at runtime (e.g. there'd be a row for Python 2.3 even if there was no Python 2.3 on your system). Basically, the problem is that we'd like to determine what goes into the ListView table at runtime, but I can only figure out how to put things into it at the time at which the .msi is built. I'm going to continue to look into this, and I'd welcome suggestions anyone has. The last resort would be to create a CustomAction using a DLL or VBScript, but I'm really trying to avoid that, both because maintaining and debugging such code is painful, and because Michael Foord suggested that some virus checkers will complain about .msi files with embedded VBScript (probably forcing me to maintain a DLL - ugh!). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5311> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com