On a *nix system, bdist_wininst.get_exe_bytes will always return an open wininst-6.0.exe. However, Windows python2.7 is compiled against msvc 9.0 and ideally would take an installer based on wininst-9.0.exe. Windows-64bit needs an installer based on wininst-9.0-amd64.exe. The ideal solution would be for bdist_wininst to take an option what "template exe" to be used. While I've monkey-patched things on my own, I'm not providing a patch as I'm not sure how the community wants to handle this (it could be anywhere from the exe name to tables being driven by target_version and some some 64bit option)
Sorry, minor correction: We could just rely on plat_name for 64bit. All that is needed is for this table: if self.target_version < "2.4": bv = 6.0 else: bv = 7.1 to be updated to python2.7 (9.0 for python2.7)
Thanks for the report. I know little about the wininst code in distutils; can you explain if this is a bug (i.e. bdist_wininst in 2.7 must use wininst-9.0-etc.exe or the installers won’t work) or a feature request (i.e. a new option to allow using newer exe files would provide some new functionality)? If it’s a bug it can be fixed in 2.7 and 3.2, otherwise it falls under the feature freeze on distutils.
Hi Eric, Quick rundown: There are template 'exe' inside distutils/command. bdist_wininst appends to the template to build a customized installer. First the 64 bit bug: http://bugs.python.org/issue6792 With that bug active, I must be able to make 64 bit windows installers for users of 64 bit windows python to install my package. Unfortunately, the only 64 bit template is wininst-9.0-amd64.exe. Due to this bug, there is no way to use that installer, preventing one from creating universal windows installers on *nix, which bdist_wininst is supposed to allowed (per documentaiton). Furthermore, I have empirically found that a 32-bit installer built against wininst-6.0 will not behave correctly either. Specifically, the pre-install-script I used would not execute. When I switched to the wininst-9.0 template, all worked fine.