This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dbn
Recipients Matt.Wilkie, dbn, eric.araujo, mhammond, tarek, theller
Date 2013-09-15.19:27:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1379273254.87.0.270474427777.issue4636@psf.upfronthosting.co.za>
In-reply-to
Content
Right, that's what makes this difficult. If the stub exe of the target python was used, then it wouldn't need to care about compatibility. However, what you're running is the stub of the build python. So, when I distribute a bdist_wininst exe, it's running the stub from my python on the user's machine. That introduces a few compatibility issues.

1. The exe needs the same CRT version installed on the target that it was built with. It would fail to run immediately in this case. This does make having the built python be newer than the target python a little difficult.

2. The exe loads the python dll on the target machine. This requires the python dll to have enough compatibility for the usage of the python API in the exe of the build version.

3. After loading the python dll, python code is run in the target python. This is the problem I'm trying to solve here. The python code is embedded in the exe of the installer, so the compatibility with the target python has to be considered at build time.

The situation you're describing where the wininst of the target is run could maybe be made to work, but it would be a larger project.
History
Date User Action Args
2013-09-15 19:27:34dbnsetrecipients: + dbn, mhammond, theller, tarek, eric.araujo, Matt.Wilkie
2013-09-15 19:27:34dbnsetmessageid: <1379273254.87.0.270474427777.issue4636@psf.upfronthosting.co.za>
2013-09-15 19:27:34dbnlinkissue4636 messages
2013-09-15 19:27:34dbncreate