-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[BUG] rich
reverts to legacy Windows APIs when stdout is redirected
#3437
Comments
rich
incorrectly falls back to legacy Windows APIs when stdout is being redirected
rich
incorrectly falls back to legacy Windows APIs when stdout is being redirectedrich
incorrectly falls back to legacy Windows APIs when stdout is redirected
rich
incorrectly falls back to legacy Windows APIs when stdout is redirectedrich
incorrectly reverts to legacy Windows APIs when stdout is redirected
rich
incorrectly reverts to legacy Windows APIs when stdout is redirectedrich
reverts to legacy Windows APIs when stdout is redirected
Given that changing the subprocess invocation to explicitly pass The long-term fix will come in Python 3.15, when https://peps.python.org/pep-0686/ makes UTF-8 mode an opt-out default, rather than its current opt-in behaviour. |
I hope we solved your problem. If you like using Rich, you might also enjoy Textual |
Describe the bug
I have an application which invokes
pdm python install ...
in a subprocess. This works fine with Unicode installation paths when run from Windows terminal (pdm
usesrich
, and one of the items it prints is the full path to the Python executable being installed).It fails when the same command is run under
pytest
, and the traceback shows thatrich
has autodetected the legacy windows console, and is trying to use thembcs
APIs instead of the fully Unicode capable Windows APIsignoring all of.PYTHONUTF8
,PYTHONIOENCODING
,PYTHONLEGACYWINDOWSFSENCODING
andPYTHONLEGACYWINDOWSSTDIO
which are set (or explicitly unset in the case of the latter two) to indicate that the legacy Windows APIs should NOT be used (and UTF-8 should be used instead)Edit: when filling this issue, I forgot the affected process was running in isolated mode, so ignoring the Python level settings would actually have been the right thing to do. Explicitly enabling UTF-8 mode in the isolated subprocess eliminated the misbehaviour.
Presumably the source of the failed detection is something
pytest
is doing (since turning off console capturing also makes the error go away), but when Python has been explicitly configured to NOT use the legacy Windows IO APIs because I know they won't work, it would be preferable ifrich
failed on startup, rather than trying to continue and then failing with a Unicode error at some later time.I also can't report the issue to
pytest
yet, because I couldn't work out from the documentation or the code exactly howrich
is deciding which set of Windows APIs to use and howpytest
might be affecting that detection process, so I decided to start here, and then hopefully have something to refer to from apytest
issue report later.The last several lines in the failing traceback showing the use of the legacy Windows console:
tox
also provokes this failure, as when the test suite is run viatox -e py3.12
instead of directly,pdm install
still reports the same exception, even thoughpytest
is being run with-s
Setting
NO_COLOR=1
in the environment does not fix the Unicode compatibility problem.Click to expand...
Platform
Windows 10, running Windows Terminal.
If you're using Rich in a terminal:
Writing a short test program to report those details from
pytest
(passing-s
to turn offpytest
's console capturing changes the diagnostic output to resemble the above):The text was updated successfully, but these errors were encountered: