[sorry for the late reply] Mark Hammond schrieb:
I'm wondering if anyone has any opinions or thoughts on how
we should handle
bdist_wininst has its own problems anyway - most severe the MSVC runtime dll issue.
What issue is this? Could it be solved by adding a manifest to the executable? It seems to me that Python itself built with VC2005 has this same issue. There is the problem of *installing* this library though, but if we assume Python itself has already done this, I don't see the problem for bdist_wininst.
The usual C runtime lib problems as it embeds Python, and also calls problematic functions in the rumtime lib, so it should use the same lib as Python itself. If you build a pure Python bdist_wininst installer, which can be used to install into Python 2.3, 2.4, 2.5, and more versions, the postinstall script (if any) does not run correctly if Python uses the wrong runtime lib.
Another one is that it won't work for 64-bit installations.
My experiments show that very nearly works! I haven't actually got such a binary to install, but a 64bit bdist_wininst based installer correctly runs all the way to asking me to select an installed Python (where it stops as I don't have such an install yet). IIUC, to get this far, bdist_wininst has already sniffed out most data it needs. I could be wrong here, but I'm wondering what problems you had in mind?
I have not tried to build a 64bit runtime stub for bdist_wininst, that's the only reason so far. It could probably be solved.
bdist_msi solves the 64-bit and MSVCRT issue. I would expect that it also solves the UAC problems. OTOH it is not possible (AFAIK) to build bdist_msi installers on Linux systems.
Yeah, that may be what I need to use going forward - which basically would leave bdist_wininst to slowly die - but I guess that is good to know now, rather than after I spend more time trying to apply life-support to it...
Well, bdist_wininst had a sucessful live, I see no problems if it is replaced with something else - be it eggs or bdist_msi.