[Distutils] bdist_wininst compatibility with pythons and windows versions

[Mark Hammond]

On 11/06/2010 6:43 PM, anatoly techtonik wrote:
> On Mon, Jun 7, 2010 at 10:01 AM, Mark Hammond<skippy.hammond at gmail.com>  wrote:
>
> build_wininst code [1] function get_exe_bytes() used to fetch
> appropriate stub, doesn't seem to be cross-platform.

Sorry, I must have misunderstood the original question - I was assuming 
the question was regarding using Windows to generate Windows installers, 
but for versions of Python other than the version being used to create 
the installer.

> More than that -
> generated installer depends on specific version of MSVC compiler that
> was used to compile Python. So it seems that there is no compatibility
> even between one Python version.

That is correct - you can't generate a single exe that works on all 
Python versions.  However, you can use an arbitrary version of Python to 
create an installer for a different arbitrary version of Python.  This 
is what pywin32 does - it uses Python 2.6/2.7 to create installers for 
Python 2.3 -> 2.7 - this results in multiple installers, but they are 
all created using a single python version.

The thorn in all this is related to the build process of the extensions 
- even though Python 2.6 can be used to create all the *installers*, 
they can't be used to build the individual components inside the 
installer.  ie, the process pywin32 uses for, eg, Python 2.3 is:

% python-2.3 setup.py build
% python-2.6 setup,py bdist_wininst --target-version=2.3

and the only reason this is done is that the bdist_wininst command in 
Python 2.6 has enhancements which aren't in 2.3, and the technique above 
allows me to take advantage of those features in those older versions.

> In addition bdist_wininst generates spurious warning about missing
> "necessary compiler setting" when run on Linux with an instruction to
> make sure win32* modules are installed (which are of course not). Even
> if wininst is strictly windows bdist, the generated .exe contains
> 'linux' suffix. Given all the above it  doesn't really seem that
> generated installer should work on windows at all. Not even speaking
> about compatibilities between Python versions or OS versions. Clearly
> that folks generating installers on Linux doesn't have any way to
> check this compatibility, so they use an older version that has all
> sorts of problems with Windows UAC [3].

Right - but I think this problem can be considered a bug in distutils 
rather than an inherent limitation - but in practice you are correct 
that the inability to build the C components used in the installer means 
that in practice this really isn't cross-platform.

Mark