Output hygiene: write to stderr by default #5049
Conversation
Only proper machine readable output should be written to stdout. This would be JSON for Cargo and `rustc`. This is only one slight patch toward this requirement, there are still other instances of writing various stuff to stdout in `rustc`.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| @@ -49,7 +49,7 @@ pub fn package(ws: &Workspace, | |||
| }).collect(); | |||
| list.sort(); | |||
| for file in list.iter() { | |||
| println!("{}", file.display()); | |||
| eprintln!("{}", file.display()); | |||
There was a problem hiding this comment.
This is machine-consumable, and is the only way to get the list of files that would be packaged AFAIK.
There was a problem hiding this comment.
I concur. However, this PR isn’t so much about distinguishing machine-readable output from human-readable output across Cargo. It is rather about distinguishing standardized, exclusively machine-readable output from ‘other’ output. So can’t we make principled decision about what ‘machine-readable’ means within Cargo? If that means making all such output JSON, then let’s do that rather than making local exceptions left and right.
There was a problem hiding this comment.
The change as-is will break code that calls this command and expects to see something on stdout.
|
The cross-compilation test ( |
|
This would undo the fix for #4884 which was just added a few weeks ago. |
|
In response to #4878 (comment):
That’s only true if you use a shell in which that’s difficult. It’s easy with e.g. fish: stderr_command ^| less
The same discussion has come up repeatedly (e.g. #1473). In this day and age, it is important to be able parse output flowing through a pipeline according to some standardized formal grammar. While it was convenient in the past to have CLI tools in which at least some crude distinction was made between ‘things you’ll want to see’ and ‘extra stuff’, there is no formal criterion to distinguish ‘output’ from ‘diagnostics’ or ‘errors’. One thing is sure, formal and natural language output don’t go well together. |
|
IIUC this bug arises because some program invokes cargo with Could this program just not use Alternatively, if very strict separation is needed, it seems that cargo could have some way to say "please be strict about stdout use" -- an environment variable or some such. |
|
Hm, so it indeed looks like we are printing some stuff to stdout which should probably go to stderr. However, I think we'll need to be more nuanced than just replacing all In particular, I believe
|
|
☔ The latest upstream changes (presumably #5041) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r? @matklad |
Strongly disagree. It should not be arbitrary where to write output to. Where did you get from that people would expect ‘hello world’-like text to appear on stdout? It makes no visual difference.
Disagree, machine readable does not mean ‘could be beaten into parseability’, but ‘comes in a standardized syntax’. Are you providing a Command Line Interface or not? By going on this way, enormous breakage will occur whenever the version output changes a bit and people rely on parsing it.
‘it is not intended for consumption by robots’ -> so it should be on stderr, not stdout. Piping will not be broken, as I explained in an earlier post. |
Overwhelming majority of hello-world programs I've seen printed the message to stdout. For example, the one at https://www.rust-lang.org does this :-) It can be argued that all hello-worlds in the world are wrong, but this is a pretty strong claim. If we want to change this, we'll need to update all the learning materials as well, so this would probably need to go through the RFC process.
People already rely on it, so, if we are going to change it, it must be a backwards-compatible change. For example, adding something like
The reasoning here is pretty similar to the hello-world case: most of over tools use stdout for help. It may be argued that all the tools are wrong, and that we should switch to stderr here. However, this should be done simultaneously across all of the Rust tools (rustc/rustup/cargo), and this is also a pretty drastic change which probably wants an RFC :-) To make it clear: I do want Cargo's output to be easier to parse, and I've even broken every other test for it :-) However there are things which we just can't change without breaking tons of code, or becoming incompatible with virtually every other tool. This doesn't mean that we can't change anything, we are not quite at the XKCD1172 level of backwards compatibility, but I think it is a good approach to separate low-risk changes from high-risk changes, and to go an extra mile to provide backward-compatibility opt-ins. |
|
@matklad: I agree, I disagree with the old habit as I expressed, but it would be better to file an RFC mandating the various ideals I argued for. Note that I don’t have a plan (yet) for actually doing it (alone). |
Only proper machine readable output should be written to stdout. This would be JSON for Cargo and
rustc. This is only one slight patch toward this requirement, there are still other instances of writing various stuff to stdout inrustc.