-
-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source and editable installs fail in some locales #1747
Comments
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this issue
Nov 28, 2023
This passes `encoding="utf-8"` to the `open` calls in setup.py, so the readme, version, and requirements files are always read as UTF-8, even on systems whose locale is not UTF-8, as is typically the case on many Windows systems for non-European languages. The specific problem was caused by the README.md file. The requirements files are less likely to contain characters not in the ASCII subset, though they could come to contain them, at least in comments. The VERSION file is even less likely to ever contain such characters. Nonetheless, for consistency, because it is a best practice, and because it appears to be the intent of the existing code, encoding="utf=8" is added for opening all of them. This change is tested on a system whose locale uses Windows code page 936. Editable installation, as well as the other affected ways of installing (and building) described in gitpython-developers#1747, are now working. (Installing from a pre-built wheel was never affected.)
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this issue
Nov 29, 2023
This passes `encoding="utf-8"` to the `open` calls in setup.py, so the readme, version, and requirements files are always read as UTF-8, even on systems whose locale is not UTF-8, as is typically the case on many Windows systems for non-European languages. The specific problem was caused by the README.md file. The requirements files are less likely to contain characters not in the ASCII subset, though they could come to contain them, at least in comments. The VERSION file is even less likely to ever contain such characters. Nonetheless, for consistency, because it is a best practice, and because it appears to be the intent of the existing code, encoding="utf=8" is added for opening all of them. This change is tested on a system whose locale uses Windows code page 936. Editable installation, as well as the other affected ways of installing (and building) described in gitpython-developers#1747, are now working. (Installing from a pre-built wheel was never affected.)
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this issue
Nov 29, 2023
This passes `encoding="utf-8"` to the `open` calls in setup.py, so the readme, version, and requirements files are always read as UTF-8, even on systems whose locale is not UTF-8. This fixes the bug described in gitpython-developers#1747 where installation other than from a pre-built wheel would fail on many Windows systems using non-European languages. The specific problem occurred with the README.md file. The requirements files are less likely to contain characters not in the ASCII subset, though maybe they could come to contain them, perhaps in comments. The VERSION file is even less likely to ever contain such characters. Nonetheless, for consistency, because it is a best practice, and because it appears to be the intent of the existing code, encoding="utf=8" is added for opening all of them. This change is tested on a system whose locale uses Windows code page 936. Editable installation, as well as the other affected ways of installing (and building) described in gitpython-developers#1747, are now working.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Methods of installing GitPython that run code from
setup.py
fail in some locales. This does not affect installing from a wheel, but it does affect installing from an sdist, or installing from a local directory, including the editable install procedure recommended for development in the readme. The same problem happens when building GitPython. Building or installing using the old method of runningsetup.py
directly is also affected. The error is of this form, though the codec will not always begbk
:I am unsure if this ever happens in practice on Unix-like systems, whose locales are usually UTF-8. However, it happens on Windows systems in which
README.md
cannot be decoded using the system's active ANSI code page. This is a rarely-changed systemwide setting, so changing the user preferred languages, display language, or input method are not workarounds. I discovered this on a Simplified Chinese (zh-CN) build of Windows Server 2022 while using it to test some WSL-related test helper logic in #1745. Such a system uses ANSI code page 936.README.md
is UTF-8, but it currently happens that it can be decoded with code page 1252, which Windows builds for Western European languages use as their ANSI code page. I expect encodings other than cp936 to fail as well.With the PyPI sdist for GitPython 3.1.40 (on Python 3.12 x86-64, though I expect all supported versions to be affected):
A workaround is to pass
-X utf8
topython
. For example,python -X utf8 -m pip install ...
can be used for installation.The fix should be straightforward. Importing
setup.py
confirms that the specific cause is readingREADME.md
:It can be fixed by passing
encoding="utf-8"
. I have proposed this change in #1748.gitdb and smmap are unaffected, because gitdb does not open files to read those data in
setup.py
, while smmap does openREADME.md
but passesencoding="utf-8"
.The text was updated successfully, but these errors were encountered: