[Python-Dev] Python merge module

[Hoyt, David]

> I hadn't thought it through fully, but the preceding paragraph really
> gets to the core of the problem. The maintenance nightmare is security
> updates for private location installations by third parties. The only
> MSI-friendly way to update that code is through releasing an updated
> merge module and having the consuming application also release an
> update that uses it. Since Python's components use fresh GUIDs each
> time, this would require a "major" upgrade; "minor" upgrades would
> cause Windows Installer to throw fits.

That's exactly right and why I said earlier that patches w/ merge modules are a pain/nightmare. But I also said that the security patching w/ a merge module would then depend on the party who has integrated the merge module into their product -- not on you guys. I don't think most (or any) parties are trying to do incremental minor updates w/ python right now anyway. With us, we just want a single, well-tested and known python implementation installed w/ our product -- we basically don't trust the user to get the right version and install it correctly. You obviously can't hold their hand every step of the way, at some point you have to let go -- but this is one thing that we could possibly control.

> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.

The general recommendation regarding msi packages is that you always, always do single-file components (one of the major reasons being for patching purposes). If you use WiX' heat application to autogenerate WiX files from directories, you'll see that it always produces single-file components.

> For contrast, I don't see a shared-location merge module as offering
> benefits beyond a silently redistributable msi package. The shared
> location is better about following component code rules (re-use in
> private areas is an allowed gray area), and there are people out there
> who consider the reference counting through merge modules to be
> superior. I find the resulting complexity in the consuming package's
> installation to be more of a down-side.

I think a merge module (shared or private) generally reduces complexity unless you already have a bootstrapper for other packages. Including one in WiX is very simple (if you're already familiar w/ msi's):

<Feature Id="Full">
    <MergeRef Id="Python" />
</Feature>

<Directory Id="TARGETDIR">
    <Merge Id="Python" SourceFile="python.msm" Language="1033" DiskId="1" />
</Directory>

If you use something like the VS installer projects, you just have to use the GUI to add a reference to it and you're done.

A shared merge module might pose a problem if you want to have multiple python versions installed. At the least, you'd need to change the component guid w/ each major release (e.g. 2.x -> 3.x, but not 2.7 -> 2.8 -> 2.9, etc.). I'd recommend w/ sticking to a private one that doesn't modify the PATH (should you choose to create one) and then you're free to keep or change the component guids.

Can python operate inside a sandboxed C:\Program Files\<My Product Here>\ directory?

> I've never tried to make a configurable merge module in WiX, but I
> think that's the only option if you want a single merge module to
> allow both. It should be a one-time authoring overhead with [1]. Using
> them is pretty straightforward within the Merge elements [2].
>
> [1] http://wix.sourceforge.net/manual-wix3/wix_xsd_configuration.htm
> [2] http://wix.sourceforge.net/manual-wix2/wix_xsd_configurationdata.htm

I wouldn't try to make it configurable (nor does it really need to be) beyond what it already should do -- that is, just be able to set the base target directory, which is already done for you. And as I just suggested, I wouldn't go for both -- declare the merge module to be private and that's that.