Michael Urman <murman <at> gmail.com> writes: > You can certainly jump through all these hoops, but the pieces here > are much more suited towards a component definition that can be shared > among multiple products. If the component always installs to the same > place, has the same GUID, and otherwise only changes by versions the > exe, this is a completely safe correct use of one. Last I knew, msi.py > allocates random GUIDs, so may or may not be suitable for generating > this. If there is only rare need to update this exe, and msi.py has > support for merge modules, that could be one approach.
I'm currently experimenting with a merge module approach: launcher_module.msm -> launcher.msi, and x64 variants in separate .amd64.ms? files. > My recommendation for distributing this: each .msi which wants to > include it should have a component that includes the following. Note > that each .exe (py, pyw) and each architecture (x86, x64) need their > own component with their own static GUID. > * Defined unchanging GUID > * Defined target location (perhaps SystemFolder) I'm doing that. > * msidbComponentAttributesSharedDllRefCount (cooperate with non-MSI > installers), msidbComponentAttributesShared (keep highest version), > and possibly msidbComponentAttributesPermanent flags set on the > component Thanks, that's interesting information. I'll read up about these. I'm a Windows installer tyro :-) > * Versioned .exe (using a Windows version block) I'm doing that, too. > * File association information Currently I'm putting the file association information in the same component as the files, since the registry values cross reference those files. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
