Replies: 1 comment 2 replies
-
Tricky one. All that comes to mind is to have an error console that shares a "record buffer". Something like the following (untested). console = Console(record=True)
error_console = Console(record=True, stderr=True)
error_console._lock = console._lock
error_console._record_buffer_lock = console._record_buffer_lock
error_console._record_buffer = record._record_buffer If that (or something like it) works, I can think about exposing it in a nicer way. Maybe |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am currently using a Console with recording enabled in order to capture output and dump it in a file when application quits.
Still this use conflicts with use of logging, which by design is supposed to send output to
stderr
and notstdout
. The problem is that if I create a new console withConsole(stderr=True)
i loose the ability to export the combined output to the file.Having two console objects makes impossible to produce useful execution report because having interlinked stdout and stderr lines are essential in order to be able to read the output.
How can I keep producing output on both stdout and stderr while being able to capture it using rich?
For the moment I am forced to disable the use of stderr for logging in one of the tools.
I am lucky that this tool is not supposed to produce machine parseable output on stdout, so the non standard use of logging may be acceptable. Still, this is not true for few other tools that I maintain which happen to be linters, and they are supposed to produce machine parseable output. For these the solution is to avoid adopting rich.logging, or to never implement the capture feature.
Please let me know if there is a solution for this use-case. Also thanks for all the time you spend on making rich easier to use.
Beta Was this translation helpful? Give feedback.
All reactions