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

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.
 * Defined unchanging GUID
 * Defined target location (perhaps SystemFolder)
 * msidbComponentAttributesSharedDllRefCount (cooperate with non-MSI
installers), msidbComponentAttributesShared (keep highest version),
and possibly msidbComponentAttributesPermanent flags set on the
component
 * Versioned .exe (using a Windows version block)
 * File association information

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