"Martin v. Löwis" <martin@v.loewis.de> writes:

M.-A. Lemburg wrote:

...

Are we going to have a VC7.1 binary of Python 2.4 for Windows ? (Just asking whether it's time to finally open the VC7 shrink- wrap box ;-)

Yes. I think it hasn't been decided whether Thomas will produce that, or yours truly.

Well, I would be much happier to build an installer with inno setup instead of Martin's msi code, which I don't understand ;-(. Are there really technical reasons the VC7.1 built Python binaries must be distributed via msi technology or not? Thomas

Thomas Heller wrote:

Well, I would be much happier to build an installer with inno setup instead of Martin's msi code, which I don't understand ;-(.

I would be willing to explain it if you would ask questions :-( What is it that you don't understand about it?

Are there really technical reasons the VC7.1 built Python binaries must be distributed via msi technology or not?

No. However, an MSI package allows distribution through group policy; an Inno Setup binary doesn't. Also, MSI supports Win64, and Inno Setup doesn't. Regards, Martin

Mark Hammond wrote:

On one hand, the code has almost no comments and assumes some knowledge of the underlying MSI mindset.

That's a valid complaint indeed.

With just a few tweaks (mainly relating to missing files), I managed to get an MSI that appears to install correctly. I think that is pretty cool :) I believe it has the basis for a reasonable MSI generator library. The hard-coding of the UI elements is unfortunate, but I see no alternative at this stage. Using distutils functions for building file lists etc would be a nice for a few reasons, least of all for a future bdist_msi :)

bdist_msi would probably need a different UI entirely, so I'll probably start from scratch for it, only using msilib.

Martin - links to articles you found enlightening while putting this together is probably the largest omission - how did you come up with this?

That's partially covered in my PyCon paper: My rationale for doing this was Win64. We have a few Itanium machines, and I wanted Python for them. I found that the VC7.1 MSI generator is useless for that purpose: You have to set the 64-bit-Bit on each "component", and VC is incapable of doing that. OTOH, it generates so many "components" that it is futile to manually fix the package it generates. I've looked around, and found that there is no freeware MSI generator which supports Win64 at this point, and apparently the commercial ones didn't, either. I also found that most MSI generators don't support the logical structuring of MSI, with components, files, directories, and so on. So I wrote my own. While trying to understand MSI, I had two primary information sources: the MSDN documentation, and ORCA.EXE. The latter tool comes with the SDK, and needs to be installed separately: The SDK installs orca.msi, which then installs orca. With orca, you can learn a lot about how other people build their MSIs, and find out how certain effects which you know are possible can be achieved. WIX was released after I had done my thing. I haven't looked at it, but I would hope that it also exposes the full power of MSI. So if people are concerned about the hackishness of my current code, I could try to come up with a WIX installer that generates roughly the same MSI package. Regards, Martin

Thomas Heller wrote:

For example, the MSI which is currently built removes the file associations when the package is removed, instead of restoring them to their previous values. I have no idea how this can be fixed...

This is a multi-step process. First, one has to find out how to restore associations in general, i.e. independently of MSI. Where should one store, on install, the information what the old association was? What if there already is "old" extension information? This is general Win32 stuff, and I don't know what the answer is. Then, how can this be integrated into an MSI file? Perhaps MSI already offers built-in mechanism for that, perhaps existing mechanisms for dealing with the registry have to be used. This is MSI specific, and is likely answered in the Microsoft MSI documentation. Then, finally, how can the Python script be changed to invoke the MSI mechanism? This is very easy: If you know what tables in MSI to manipulate in what way, the relevant Python code should become easily apparent. So in this case, I don't think any amount of documentation on the Python script will help to solve this problem (that is not to say that documentation should be avoided for this reason, of course). Regards, Martin

Thomas Heller wrote:

Wise gives an example. It stores the previous value in it's INSTALL.LOG file. Whether this makes sense in general or not I cannot tell, although it's convenient for me.

This is unreliable, of course: the original software may get uninstalled, in which case uninstall would restore an invalid association. Or, something might install on top of Python, and back up the Python association in its own logfile. Then, uninstalling Python would break the associations of that software. I just learned in microsoft.public.platformsdk.msi that Windows does not have a mechanism for that feature, and neither does MSI.

I thought MSI were able to 'restore the system to the state it had before the installation', but maybe this is just a dream, may it isn't supposed to do this, maybe one has to use system restore points for that, and maybe this only shows how much I know about this stuff.

MSI does support rollbacks; invoking a rollback is supposed to fully restore the system to its original state (although the MSI author has to work to make sure it really does in all cases). However, rollback only applies to the installation. If, in the course of the installation, something fails (e.g. an essential file cannot be written, because permissions are incorrect), installer will invoke a rollback and restore all original registry keys. Once the installation is committed, rollback is not possible anymore (and installer removes the Cancel button from the UI after the commit until the end of the installation).

Well, the docs for msilib could tell that associations are not restored.

Actually, msilib is (currently) completely unaware of associations. The Python associations are generated in the fragment starting # File extensions, associated with the REGISTRY.def component # IDLE verbs depend on the tcltk feature. # msidbComponentAttributesRegistryKeyPath = 4 # -1 for Root specifies "dependent on ALLUSERS property" ... add_data(db, "Registry", [# Extensions ("py.ext", -1, r"Software\Classes\."+ext, "", "Python.File", "REGISTRY.def"), This is literally what it says it is: it adds data to the Registry MSI table. See the documentation of the Registry table for details of the fields. Installer, in turn, literally does what the Registry table tells it to do: it adds keys to the registry. If you want to perform backup of the existing registry keys to a file, you need a Custom Action.

BTW: Python-2.4a1.msi misses to install the distutils/command/wininst-6.exe file. Should I fix this myself (i guess I could figure *this one* out) or do you prefer a bug report?

Please go ahead and make any changes to the scripts you feel necessary. If you are uncertain, make a patch and assign it to me. If you don't know how to make a patch, or have no time to do so, submit a bug report. Regards, Martin