2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.

At least is was reported that compiled binaries contains wrong platform name, i.e. 'linux' and there are errors about inability to look up some compiler options in windows registry while building.

Where was that reported?

In this SCons thread http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2617686

$ python setup.py build bdist_wininst
running build
running build_py
running bdist_wininst
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
copying build/lib.linux-i686-2.6/wget.py -> build/bdist.linux-i686/wininst/PURELIB
running install_egg_info
Writing build/bdist.linux-i686/wininst/PURELIB/wget-0.6.egg-info
creating '/tmp/tmpQQZI5O.zip' and adding '.' to it
adding 'PURELIB/wget-0.6.egg-info'
adding 'PURELIB/wget.py'
creating dist
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
removing 'build/bdist.linux-i686/wininst' (and everything under it)
$ ls dist
wget-0.6.linux-i686.exe

The error comes from the msvccompiler module, which shouldn’t get used on non-Windows platforms unless I’m mistaken. Reading the module, I’m not sure at all this command was meant to be run on not-Windows OSes.

It did run ok on non-Windows OSes with previous Python versions.

It certainly should be possible to build these installers, and if I understand your output correctly, an installer *was* built.  The warning is, after all, just a warning, and probably just the warning got added compared to 2.5, but the behavior is the same.

The platform name is a regression though.

The regression is two-fold:

1. platform name regression is caused by r62197 by Mark Hammond - Issue #2513: enable 64bit cross compilation on windows

2. when wininst stub selection started to depend on MSVC compiler version is yet to be investigated, but I am sure that wininst stub selection should only be affected by compatibility with operating system only

More complete research notes are at  https://wave.google.com/wave/waveref/googlewave.com/w+GnQ9tjc8A

http://codereview.appspot.com/1774043

Did you test that patch? ISTM that it contains a syntax error:

+        if not self.distribution.has_ext_modules()
+            and not self.distribution.has_c_libraries():

reuploaded correct version to rietveld.

With the caveat that I haven't tested it (I'm currently traveling), the patch looks good to me.

Raising priority.

I get an error trying to run the command because of the use of the mbcs codec.

Ezio made some comments on Rietveld, I addressed them in a local clone.

Question for Windows users/experts: Do the terms “binary extension” and “binary code” make sense?  If not, I can change them to the clearer “extension modules” and “C code”.

Fixed Ezio comments at http://codereview.appspot.com/1774043

Eric, if I understand you correctly, the mbcs issue you're experiencing is unrelated to the patch. What else do you need?

Is this issue really critical? 
Bump.

I opened another bug for the MBCS problem which prevents me from testing Anatoly’s patch.

2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup.

2.6 only gets security fixes.

Éric: In http://bugs.python.org/issue8954#msg135902 are you saying:

This issue needs to be re-targeted to a newer Python.
Close -- won't fix.
Something else?

This issue seems to be stuck here, any ideas on what needs to be done to move this forward?

Sean: In msg135902 I am merely explaining why I removed 2.6 from the list of versions.  Only 2.7, 3.2 and 3.3 can get fixed.

If you look at my previous message or the list of dependencies, you can see that #10945 needs to be fixed first before I can review the patch provided for this issue.

I was looking over this patch (as it relates to my bug report: http://bugs.python.org/issue14877?@ok_message=msg%20161314%20created%3Cbr%3Eissue%2014877%20message_count%2C%20messages%20edited%20ok&@template=item) and noticed that this line:

+        if (not self.distribution.has_ext_modules() and 
+            not self.distribution.has_c_libraries()):
+            basename = "%s.%s" % (fullname, "win32")

I feel it may be better to insert plat_name there if it exists. That way, users can create installers targeted for win-amd64.  Why is this needed for a pure python packages? This bug: http://bugs.python.org/issue6792

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools