You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bdist_wininst depends on MBCS codec, unavailable on non-Windows #55154
If distutils.commands.bdist_wininst.bdist_wininst.get_inidata returns a unicode string (which is always the case in 3.x and can happen in 2.x if if you pass a unicode object as one setup argument), bdist_wininst will try to use the MBCS codec, which is not available on non-Windows OSes (see http://docs.python.org/dev/library/codecs#module-encodings.mbcs).
Please don't ask me about patches. Core devs won't accept them.
One of your patches for diff has been accepted; some distutils bugs have
patches from you (for which we are grateful) that are in various review
stages. The only thing preventing acceptance where I’m concerned is
time, nothing else.
runtux commented on May 13, 2011
runtuxmannequin
Mannequin
More actions
I've just been bitten by this when trying to do a new release of roundup, why not make the mbcs codec available on non-windows platforms as has been proposed (and rejected) in bpo-1251921 -- any non-technical reasons for not including this codec on other platforms?
The mbcs codec depends on the Windows installation. On most Western Windows it is similar to cp1252, Japanese Windows will use cp932, and so on.
If we were to provide mbcs on non-windows platform, it should be an alias to ascii.
Can't you only work with Unicode and avoid the MBCS encoding?
runtux commented on Jul 7, 2011
runtuxmannequin
Mannequin
More actions
On Thu, Jul 07, 2011 at 10:52:51AM +0000, STINNER Victor wrote:
Can't you only work with Unicode and avoid the MBCS encoding?
I'm trying to build a windows binary package on Linux. This usually
works fine -- as long as the package description doesn't contain
unicode. If it *contains* unicode it will somehow internally use MBCS
encoding.
So if someone fixes windows binary package building on non-windows
platforms to not use MBCS encoding this is fine with me. But maybe the
easier way out here is to include that codec on all platforms.
(and don't tell me I have to install windows for building a windows
binary package :-)
Can't you only work with Unicode and avoid the MBCS encoding?
It is not code under the users’ control (i.e. setup.py) that uses MBCS, but the bdist_wininst command itself. It used to be runnable from linux, which is great to provide binary installers for Windows users who typically don’t have a compiler. This is what the bug is about.
It is not code under the users’ control (i.e. setup.py)
that uses MBCS, but the bdist_wininst command itself.
bdist_command append configuration data to a wininst-xxx.exe binary. Where does this file come from? Can we modify wininst-xxx.exe binaries?
If we can modify the binaries, we can change the format to store the configuration data as UTF-8 instead of the ANSI code page.
It's surprising and "unsafe" (not portable) to use the ANSI code page for an installer: if you build your installer on a french setup (ANSI=cp1252), the configuration was be interpreted incorrectly on a japanese setup (ANSI=cp932). Example:
>>> 'Hé ho'.encode('cp1252').decode('cp932')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'cp932' codec can't decode bytes in position 1-2: illegal multibyte sequence
So if the configuration data (package metadata) contains non-ASCII characters, you will not be able to use your installer on a computer using a different ANSI code page than the code page of the computer used to build the installer... In the best case, you will just get mojibake.
If we cannot modify wininst-xx.exe, an alternative to be able to generate installers on non-Windows platforms is to use the most common ANSI code page (cp1252?), or maybe ASCII.
Use the ASCII encoding is the safest solution because you will be able to use your installer on all Windows setup (all ANSI code pages are compatible with ASCII), but you will not be able to generate an installer if the package metadata contains at least one non-ASCII character...
> It is not code under the users’ control (i.e. setup.py)
> that uses MBCS, but the bdist_wininst command itself.
bdist_command append configuration data to a wininst-xxx.exe binary.
Are you sure? The string that’s encoded with mbcs comes from the get_inidata method in bdist_wininst.py; get_inidata only works with strings (either string literals or str objects (in 3.x) given as attributes of the command object or in the DistributionMetadata object).
Where does this file come from? Can we modify wininst-xxx.exe binaries?
If needed, we can: the code lives in PC/bdist_wininst.
Use the ASCII encoding is the safest solution
I don’t think so. Distutils supports author='Éric', so bdist_wininst should too :)
The proposition of using other C functions and changing the bdist_wininst code looks risky to me, especially as I don’t know how compatibility would be affected (see my previous message). We are free to improve the wininst code in distutils2, or discuss a replacement (Jeremy Kloth was working on something with all the features of MSI and wininst), but for distutils I would very much prefer the simplest fix that could possibly works.
bdist_msi decodes data read from setup.py with MBCS on Windows; on other OSes, couldn’t the locale preferred encoding be used?
Would the proposed change mean that a bdist_wininst built
with 3.2.0 won’t work with a patched 3.2.3?
The installer doesn't use distutils to read its configuration, so such binary runs with any installed Python version.
bdist_msi decodes data read from setup.py with MBCS on Windows;
on other OSes, couldn’t the locale preferred encoding be used?
It would be worse: Linux doesn't use Windows code page. Most modern OSes are now using UTF-8 locale encoding, whereas Windows never use UTF-8 as the ANSI code page.
changed the title [-]bdist_wininst depends on MBCS codec, unavailable on non-Windows[/-][+]bdist_wininst depends on MBCS codec, unavailable on non-Windows[/+]on Apr 7, 2013
hroncok commented on Jul 1, 2019
hroncokmannequin
Mannequin
More actions
I've opened a PR thet removes the support for bdist_wininst on non-Windows. Apparently, it was broken since the beginning of Py3k anyway. The support can be reintroduced once it is actually fixed (or never).
I've opened a PR thet removes the support for bdist_wininst on non-Windows. Apparently, it was broken since the beginning of Py3k anyway. The support can be reintroduced once it is actually fixed (or never).
It would be better to use the Unicode (wide character) flavor of the Windows API to avoid completely any explicitly encoding, and only pass Unicode strings. But This issue is open for 8 years and it seems like nobody cares enough to invest time to implement such change.
So I'm fine with trivial PR 14506. It doesn't change the status quo: bdist_win was always broken on non-Windows platforms since Python 3.0, but the PR makes the status quo more obvious which is a good thing.
New changeset 72cd653 by Victor Stinner (Miro Hrončok) in branch 'master': bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506) 72cd653
Activity
merwok commentedon Jan 19, 2011
If distutils.commands.bdist_wininst.bdist_wininst.get_inidata returns a unicode string (which is always the case in 3.x and can happen in 2.x if if you pass a unicode object as one setup argument), bdist_wininst will try to use the MBCS codec, which is not available on non-Windows OSes (see http://docs.python.org/dev/library/codecs#module-encodings.mbcs).
If someone wants to make a patch, here are some guidelines: http://wiki.python.org/moin/Distutils/FixingBugs
techtonik commentedon Jan 19, 2011
I believe it is better to start and commit a testcase .
merwok commentedon Jan 19, 2011
We don’t commit failing tests :) If you mean you want to write a test case, please go ahead and attach a patch or changeset URI.
techtonik commentedon Jan 19, 2011
Please don't ask me about patches. Core devs won't accept them.
merwok commentedon Jan 19, 2011
One of your patches for diff has been accepted; some distutils bugs have
patches from you (for which we are grateful) that are in various review
stages. The only thing preventing acceptance where I’m concerned is
time, nothing else.
runtux commentedon May 13, 2011
I've just been bitten by this when trying to do a new release of roundup, why not make the mbcs codec available on non-windows platforms as has been proposed (and rejected) in bpo-1251921 -- any non-technical reasons for not including this codec on other platforms?
amauryfa commentedon May 13, 2011
The mbcs codec depends on the Windows installation. On most Western Windows it is similar to cp1252, Japanese Windows will use cp932, and so on.
If we were to provide mbcs on non-windows platform, it should be an alias to ascii.
vstinner commentedon Jul 7, 2011
Can't you only work with Unicode and avoid the MBCS encoding?
runtux commentedon Jul 7, 2011
On Thu, Jul 07, 2011 at 10:52:51AM +0000, STINNER Victor wrote:
I'm trying to build a windows binary package on Linux. This usually
works fine -- as long as the package description doesn't contain
unicode. If it *contains* unicode it will somehow internally use MBCS
encoding.
So if someone fixes windows binary package building on non-windows
platforms to not use MBCS encoding this is fine with me. But maybe the
easier way out here is to include that codec on all platforms.
(and don't tell me I have to install windows for building a windows
binary package :-)
Thanks, Ralf
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: http://www.runtux.com
Reichergasse 131, A-3411 Weidling email: [email protected]
osAlliance member email: [email protected]
merwok commentedon Oct 9, 2011
haypo:
vstinner commentedon Oct 14, 2011
bdist_command append configuration data to a wininst-xxx.exe binary. Where does this file come from? Can we modify wininst-xxx.exe binaries?
If we can modify the binaries, we can change the format to store the configuration data as UTF-8 instead of the ANSI code page.
It's surprising and "unsafe" (not portable) to use the ANSI code page for an installer: if you build your installer on a french setup (ANSI=cp1252), the configuration was be interpreted incorrectly on a japanese setup (ANSI=cp932). Example:
So if the configuration data (package metadata) contains non-ASCII characters, you will not be able to use your installer on a computer using a different ANSI code page than the code page of the computer used to build the installer... In the best case, you will just get mojibake.
If we cannot modify wininst-xx.exe, an alternative to be able to generate installers on non-Windows platforms is to use the most common ANSI code page (cp1252?), or maybe ASCII.
Use the ASCII encoding is the safest solution because you will be able to use your installer on all Windows setup (all ANSI code pages are compatible with ASCII), but you will not be able to generate an installer if the package metadata contains at least one non-ASCII character...
merwok commentedon Oct 14, 2011
4 remaining items
merwok commentedon Oct 17, 2011
Would the proposed change mean that a bdist_wininst built with 3.2.0 won’t work with a patched 3.2.3?
merwok commentedon Mar 13, 2012
The proposition of using other C functions and changing the bdist_wininst code looks risky to me, especially as I don’t know how compatibility would be affected (see my previous message). We are free to improve the wininst code in distutils2, or discuss a replacement (Jeremy Kloth was working on something with all the features of MSI and wininst), but for distutils I would very much prefer the simplest fix that could possibly works.
bdist_msi decodes data read from setup.py with MBCS on Windows; on other OSes, couldn’t the locale preferred encoding be used?
vstinner commentedon Mar 13, 2012
The installer doesn't use distutils to read its configuration, so such binary runs with any installed Python version.
It would be worse: Linux doesn't use Windows code page. Most modern OSes are now using UTF-8 locale encoding, whereas Windows never use UTF-8 as the ANSI code page.
[-]bdist_wininst depends on MBCS codec, unavailable on non-Windows[/-][+]bdist_wininst depends on MBCS codec, unavailable on non-Windows[/+]hroncok commentedon Jul 1, 2019
I've opened a PR thet removes the support for bdist_wininst on non-Windows. Apparently, it was broken since the beginning of Py3k anyway. The support can be reintroduced once it is actually fixed (or never).
#14506
vstinner commentedon Jul 1, 2019
It would be better to use the Unicode (wide character) flavor of the Windows API to avoid completely any explicitly encoding, and only pass Unicode strings. But This issue is open for 8 years and it seems like nobody cares enough to invest time to implement such change.
So I'm fine with trivial PR 14506. It doesn't change the status quo: bdist_win was always broken on non-Windows platforms since Python 3.0, but the PR makes the status quo more obvious which is a good thing.
vstinner commentedon Jul 1, 2019
I started a discussion on the Packaging list:
"Deprecate bdist_wininst"
https://discuss.python.org/t/deprecate-bdist-wininst/1929
vstinner commentedon Jul 1, 2019
New changeset 72cd653 by Victor Stinner (Miro Hrončok) in branch 'master':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
72cd653
miss-islington commentedon Jul 1, 2019
New changeset 45c10da by Miss Islington (bot) in branch '3.7':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
45c10da
miss-islington commentedon Jul 1, 2019
New changeset be5bb52 by Miss Islington (bot) in branch '3.8':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
be5bb52
vstinner commentedon Jul 1, 2019
Follow-up issue: bpo-37468 "Don't install wininst*.exe on non-Windows platforms".
vstinner commentedon Jul 2, 2019
Lib/distutils/tests/test_bdist_wininst.py contains an interesting comment linking to bpo-5731:
Related commit:
commit ad95826
Author: Tarek Ziadé <[email protected]>
Date: Thu Apr 9 21:36:44 2009 +0000
But there is also bpo-8954 follow-up which is still open: "wininst regression: errors when building on linux".
vstinner commentedon Jan 11, 2021
The distutils bdist_wininst command has been removed in Python 3.10: see bpo-42802.