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
CliRunner
: restrict mix_stderr
influence to <output>
; keep <stderr>
and <stdout>
stable
#2522
Milestone
Comments
kdeldycke
changed the title
May 30, 2023
CliRunner
: restrict mix_stderr
influence to output
only; keep <stderr>
and <stdout>
constantCliRunner
: restrict mix_stderr
influence to <output>
only; keep <stderr>
and <stdout>
constant
kdeldycke
changed the title
May 30, 2023
CliRunner
: restrict mix_stderr
influence to <output>
only; keep <stderr>
and <stdout>
constantCliRunner
: restrict mix_stderr
influence to <output>
; keep <stderr>
and <stdout>
stable
6 tasks
I just finished a PR at: #2523 It is ready to be reviewed and/or merged upstream. |
kdeldycke
added a commit
to kdeldycke/click
that referenced
this issue
Feb 23, 2024
Closes pallets#2522 [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Let's start with the current behaviour of
CliRunner
regarding itsmix_stderr
option.Here is a simple CLI:
When called, the CLI above produces:
What I'd like to propose is to instead have
CliRunner
produce this result:So what I propose is to streamline the semantics of
result.stdout
,result.stderr
andresult.output
:result.stdout
always contain the pure output to<stdout>
. Never mangle<stderr>
in it.result.stderr
always contain the pure output to<stderr>
. Never raise an error.result.output
as the content the user is expected to see:<stdout>
ifmix_stderr=False
<stdout>
and<stderr>
ifmix_stderr=True
The advantage of this is we could properly check the individual
<stdout>
and<stderr>
streams, and check for the user output by inspecting<output>
.The raised exception in
<stderr>
has been introduced in7.0
for backward compatibility, because the code prior to7.0
wasn't returning thestderr
/stderr
split output (see #868). It's from 2017 so we can safely change that behaviour by now.Note that I explicitely numbered each
echo()
statement to highlight the print order. If a refactor is attempted, I am anticipating some edge-cases around the preservation of order, so it's good to have simple code to test that.The text was updated successfully, but these errors were encountered: