Repository navigation
bdist_wininst fails on py3k #49326
Description
| BPO | 5076 |
|---|---|
| Nosy | @loewis, @mhammond |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/mhammond'
closed_at = <Date 2009-01-29.13:13:15.517>
created_at = <Date 2009-01-27.06:03:13.520>
labels = ['type-bug', 'library']
title = 'bdist_wininst fails on py3k'
updated_at = <Date 2009-01-29.19:20:08.028>
user = 'https://github.com/mhammond'bugs.python.org fields:
activity = <Date 2009-01-29.19:20:08.028>
actor = 'loewis'
assignee = 'mhammond'
closed = True
closed_date = <Date 2009-01-29.13:13:15.517>
closer = 'mhammond'
components = ['Distutils']
creation = <Date 2009-01-27.06:03:13.520>
creator = 'mhammond'
dependencies = []
files = ['12873', '12886']
hgrepos = []
issue_num = 5076
keywords = ['patch']
message_count = 8.0
messages = ['80622', '80632', '80637', '80662', '80692', '80726', '80762', '80778']
nosy_count = 2.0
nosy_names = ['loewis', 'mhammond']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = 'commit review'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5076'
versions = ['Python 3.0', 'Python 3.1']
Activity
mhammond commentedon Jan 27, 2009
bdist_wininst installers created by py3k fail due to PySys_SetArgv and
Py_SetProgramName both being passed 'char *' strings instead of wide
strings.
The patch is against the svn trunk as currently Python 2.x and 3.x share
the same bdist_wininst stub. The patch doesn't change the behaviour on
Python 2.x, and continues to allow the same executable stub to be
shared, as the appropriate signature is determined at runtime based on
the Python version.
The patch does not include the 2 new stub executables required
(wininst-9.0.exe and wininst-9.0-amd64.exe), but the patch *and* the new
stub executables should be merged into whatever py3k branches are
appropriate. I've tested (pywin32) installers based on the new stub on
python 2.6 32bit, and python 3.0 32 and 64bit.
loewis commentedon Jan 27, 2009
Is it really useful to be have the same stub for 2.x and 3.x? I think it
would be better if they mutually ignore each other, and be different.
mhammond commentedon Jan 27, 2009
On a related note, its obviously true that the same final installer will
not be able to be shared between 2.x and 3.x, as is currently possible
between pure-python installers between the 2.x series. However, this
could be addressed in .py code at a later time while still allowing the
same stub to be shared if that is desirable.
loewis commentedon Jan 27, 2009
It's still possible to merge changes reasonably even if the "target"
(i.e. py3k) differs slightly from the source. Therefore, I think the 3k
version should unconditionally only support python3x.dlls. IOW, let
the sources diverge (for sake of simplicity of each individual source).
mhammond commentedon Jan 28, 2009
Attaching an updated patch against the py3k branch which makes no
attempt to work on py2k.
loewis commentedon Jan 28, 2009
This patch is fine, please apply.
I wish it wouldn't be necessary to widen char*, but start off with
wchar_t from the beginning. AFAICT, this would work fine for argv[1]
(there are only two arguments, anyway), but might get complicated for
argv[0].
mhammond commentedon Jan 29, 2009
Checked into py3k as r6998; merged to release30-maint as 69099. I hope
I got that right!
loewis commentedon Jan 29, 2009
If you ask whether checking into py3k was the right thing: yes, it was.