[Python-Dev] [Python-3000] 2.6.1 and 3.0

["Martin v. Löwis"]

Giovanni Bajo wrote:
> On gio, 2008-11-27 at 00:29 +0100, "Martin v. Löwis" wrote:
>>> So, deducing from your reply, this "merge module" is a thing that allows
>>> to install the CRT (and other shared components)? 
>> Correct. More generally, a merge module is a something like an MSI
>> library (.a). It includes a set of files and snippets of an installation
>> procedure for them.
> 
> OK. One question: why CRT doesn't get installed as regular files near to
> the python executable? That's how I usually ship it, but maybe Python
> has some special need.

When installing "for all users", pythonxy.dll goes into system32. This,
in turn, requires the CRT to be installed globally (which meant into
system32 for VS6 and VS7.1, but means using SxS for VS 2008). It's
necessary to install it into system32 so that PythonCOM can find it
(alternatively, we could now also making it an SxS assembly).

VS2008 adds another twist: assembly manifests. As a consequence of this
technology, if Python 2.6 is installed "just for me" on Windows Vista
(i.e. the CRT is next to the executable), it just won't work, because
the extension modules (.pyd) can't find the CRT.

> I proposed an alternatives because I read you saying: "The tricky part
> really is when it breaks (which it does more often than
> not), in which case you need to understand msi.py, for which you need to
> understand MSI". Which means that maybe everybody *has tools* to build
> an installer today, but only a few people have the required knowledge to
> really do releases on Windows.
> 
> So I believe that switching to an alternative that doesn't require full
> understanding of MSI and msi.py would probably low the barrier and allow
> more people to help you out.

I remain skeptical. You replace the need to learn MSI with the need to
learn this tool, and not only to work around the limitations of MSI, but
also around the limitations of the tool you have chosen.

Regards,
Martin