The 3.0a2 installer requires the user to install the VS CRT library
manually. 3.0a3 and 2.6a1 should automate the installation of vsredist
somehow.

I tried running vcredist from within the python MSI. That aborts with
error message that it can't run another installer while one is already
running.

As taken from http://blogs.msdn.com/astebner/
archive/2006/08/23/715755.aspx

"Hi Didier - You should not try to install this vcredist package using 
a nested install.  Performing nested installs causes problems with 
installing hotfixes for the child packages.  You will need to use some 
kind of chainer to launch the vcredist setup package in silent mode, 
and then launch your main MSI setup afterwards."

vcredist 8 information: http://blogs.msdn.com/astebner/
archive/2007/02/07/update-regarding-silent-install-of-the-vc-8-0-
runtime-vcredist-packages.aspx

Some hints on how to redistribute vc++ libraries:

http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-
visual-c-libraries-with-your-application.aspx

asmodai, which details in these postings are you referring to
specifically? I find none of them helpful, wrt to packaging Python.

The hints that the vcredist cannot/should not be installed nested, but 
should be chained.
The details on the full flags used/supported by the vcredist files.
And the last one how to do the merge modules (and some other 
scenario's) way of adding the dependency.

I have no idea of the level of Windows development of people, but at 
least this way some of the background information is logged somewhere.

> The hints that the vcredist cannot/should not be installed nested, but 
> should be chained.

So how do I do chaining if I can only ship a single MSI file (which is
my objective)?

> The details on the full flags used/supported by the vcredist files.

I don't think using vcredist can work at all. I would be happy to
be proven wrong, but I really cannot see a solution to use it. Instead,
I believe the merge module must be used.

> And the last one how to do the merge modules (and some other 
> scenario's) way of adding the dependency.

Which way specifically are you referring to? Using Visual Studio?
I don't think Visual Studio is capable of producing the output
that we desire (but again, I would be happy to be proven wrong).

OK, I played around a bit and created a setup project (.vdproj file).

The relevant part for the merge modules is:

        "MergeModule"
        {
            "{CEE29DC0-9FBA-4B99-8D47-5BC643D9B626}:_8968169979C7478FA06F2A63790836FB"
            {
            "UseDynamicProperties" = "11:TRUE"
            "IsDependency" = "11:TRUE"
            "SourcePath" = "8:microsoft_vc90_crt_x86.msm"
                "Properties"
                {
                }
            "LanguageId" = "3:0"
            "Exclude" = "11:FALSE"
            "Folder" = "8:"
            "Feature" = "8:"
            "IsolateTo" = "8:"
            }
            "{CEE29DC0-9FBA-4B99-8D47-5BC643D9B626}:_B6A9939311C545EBB80282DDFF193627"
            {
            "UseDynamicProperties" = "11:TRUE"
            "IsDependency" = "11:TRUE"
            "SourcePath" = "8:policy_9_0_Microsoft_VC90_CRT_x86.msm"
                "Properties"
                {
                }
            "LanguageId" = "3:0"
            "Exclude" = "11:FALSE"
            "Folder" = "8:"
            "Feature" = "8:"
            "IsolateTo" = "8:"
            }
        }

One thing I read is that these setup projects (and perhaps the merge 
modules) are not supported on the express editions and needs to do the 
xcopy routine.

Let me know if I should attach my .vdproj, right now it is hardcoded in 
some places, but it creates a .MSI with the following:

catalog.21023.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
_15FEE25FEEA5B2FA5906FBB18964EA25
_39CC7CD67C9CC4024DB4457CAD1D8F4B
_64A91316C96BFF833C45602D2342A095
_F11BA2FBEC12D0CBA986C9D17E9781C0

So on that front I think it is a mission accomplished, now to tweak and 
tune.

> So on that front I think it is a mission accomplished, now to tweak and 
> tune.

Please do attach the project. I can't quite understand what it is that
you have achieved. Is that a project file that can create a full Python
installer?

Hi Martin,

yes, that's exactly what I am saying actually. :)

This is the resulting file I created: Python26.msi
Right now it only installs into C:\Python26 and puts python.exe, 
pythonw.exe and python26.dll there, but it is a start.

In pcbuild.sln this entry was added:

Project("{54435603-DBB4-11D2-8724-00A0C9A8B90C}") = "Python26", 
"Python26\Python26.vdproj", "{B4DFC5BC-6BEA-41B7-9A40-663F2677E506}"
EndProject

The Python26.vdproj is attached.

More work needs to be done, of course, but I merely wanted a proof of 
concept for a project file that could build a .msi and had the 
appropriate MSM integrated.

Ok, I never doubted VS can do merge modules (what else if not VS could
do so?). What I'm still questioning that it is possible to do a full
Python installer as a VS setup project. I personally don't think it's
even worth the effort to try, but I might be wrong.

As far as I understood recent commits Martin has figured out how to
integrate the VS CRT redist merge modules into the MSI installer. Am I
correct?

Correct. This is now fixed.