bdist_wininst attempts to use the correct MSVC runtime
for the current version of Python.  This doesn't work
correctly when --target-version is set.  In that case,
bdist_wininst still uses the *current* sys.version (ie,
2.4) rather than the version specified as
--target-version.  Thus, the msvc7 runtime based
executable stub is *always* used.

This patch "hard-codes" knowledge of earlier Python
versions, providing the correct result when Python 2.4
is used to build Python 2.3 and earlier distributions.

As the comments in the patch mention, another
alternative is to allow --target-version to specify a
Python executable instead of a simple version string,
and execute that Python to parse its sys.version.  Let
me know if you think that is a good/better idea.

Assigning to Thomas for review, then please assign back.

Logged In: YES 
user_id=11105

The situation is even worse.

--target-version is only available for pure-Python
distributions which don't have extension modules, if you
want to restrict the installer to only one version of
Python, for whatever reason.  I could never think of a
reason, but now there is one: different MSVC runtimes used
in the target Python.

Running a Python executable to determine the MSVC runtime
does not work: First, usually you build installers for other
users, second, some people build windows installers on
non-windows systems.

I have no idea how this can be solved, except of a very old
one of mine: build and execute the installer on the target
system ;-)

Logged In: YES 
user_id=11105

Maybe bdist_wininst must be changed to (hard-coded) only
accept 2.4 and higher when 2.4 is used to build the
installer, and only accept 2.3 and lower otherwise?

For the other idea (building the installer on the target
system): we could run 'setup.py build_ext' on the source
system, maybe repeat this for different Python versions if
available, zip up the source and build tree (including
compiled extensions), and then run 'setup.py bdist_wininst'
on the target system, and then execute the exe?

This would also allow to have cross version support,
including extensions, in one installer file.

Logged In: YES 
user_id=14198

I'm not exactly sure what you are saying.  The current
version of bdist_wininst allows you to specify
--target-version and --skip-build, thereby allowing this to
target *any* version of Python.  If target_version !=
sys.version, the package has extensions and --skip-build is
not specified, an error is thrown.

So, I *build* the extensions using the "native" version of
Python, but want to *package* the installer using CVS trunk
disutils.  This last step has --skip-build specified, and
works fine.

So I can't see the problem you allude to.  Further, it works
just fine with my patch using Python 2.4 to package up my
2.3/2.2 based installers.  Unfortunately, I'm not even sure
if you are saying Python 2.4 distutils should be able to
package 2.3/2.2 based packages.

My idea of specifying the executable would be an option.  My
suggestion is that this would be used simply so Python could
extract the sys.version for that version, and parse the C
compiler used as it does now for the current version.  It
would simply allow disutils to extract more information
about the target version than "x.y", and may allow us to
better support non MS compilers (as a comment in the
existing code mentions).  Of course, if they are building
without that target version available, then they can stick
to supplying just the target version number, as now.

Logged In: YES 
user_id=11105

Ah, now I understand.
I didn't even know that it was possible to use
--target-version and --skip-build to build installers for
other Python versions, but this is definitely cool.

I checked in your patch to make sure it gets into 2.4a1.
Your idea to specify an executable makes sense, but imo only
when 2.4 is an old version, isn't it?  Feel free to provide
an additional patch for that, but I think one should still
be able to use '2.3' as argument for the --target-version
switch.

BTW: The short variant of the --target-version switch (-v)
conflicts with the --verbose option and doesn't work, so I'm
taking this out as well.

Checked in as bdist_wininst.py rev 1.49.

Logged In: YES 
user_id=21627

I'd like to mention that --target-version isn't really
needed, IMO: it is relatively easy to just use the old
Python executable to run setup.py, and it will automatically
use the old distutils.

Logged In: YES 
user_id=14198

The point is to use a *new* distutils with an old Python
version - ie, I want to use the latest distutils features to
build a Python 1.5.2 distribution.

OK, maybe not 1.5.2 anymore <wink>

Logged In: YES 
user_id=11105

Hm, it's not as cool as I thought - you only get the new
distutils features from the bdist_wininst command, not from
other commands.  For example, the new 'package_data' option
doesn't work for target-version 2.3, since the build tree is
still created with the 2.3 distutils.

Was open, but marked as "Fixed" - closing.