[Python-Dev] PEP 397 (Python launcher for Windows) reference implementation (original) (raw)

Michael Urman murman at gmail.com
Tue Jul 5 15:38:54 CEST 2011

On Tue, Jul 5, 2011 at 03:01, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

Were those other Windows apps packaged as .msi, or .exe? AFAICT, although you can embed an MSI inside another one, the practice of concurrent/nested installations is strongly discouraged by Microsoft - see http://goo.gl/FJx1S (Rule 20).

Right, you cannot sanely embed one .msi inside another .msi; the support for "nested" or "concurrent" installations referred to in that link is indeed something to avoid.

So you could package Python and the launcher as separate MSIs (this would make sense so that you could restore associations to the launcher just by repairing its installation), but since nested MSIs are a no-no, that means installing via a bootstrapping .exe. This is a bigger change to our Windows packaging than some people might be comfortable with ...

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.

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.

Then these components can be included in the python 3.3 installer, future releases, and even a standalone installer, and reference count correctly. Again, these can optionally be made available as merge modules for other consumers, but there's likely no need.

-- Michael Urman

More information about the Python-Dev mailing list