-
-
Notifications
You must be signed in to change notification settings - Fork 985
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
fix(#2123): Move output to stderr #2125
Conversation
This change moves informational command outputs from console.log (prints on stdout) to console.warn/console.error (prints on stderr) to enable stdout processing in pipelines.
Hey, is there anything I can do to improve this PR to get it merged? :) |
Friendly ping :) |
Do you happen to have feedback on this one too, @andreassiegel? Your feedback on the one was valuable to me! Thanks! |
Hi @jzorn, While I absolutely understand and like the idea of being able to build up command chains and to pipe the output into other tools like So, to me, this felt like a "misuse" of output streams due to the conflict between "actual" (result) output and intermediate log information. This relates to my personal work context as a backend engineer: I'm trying to be careful about log levels and want to make conscious decisions about when to use which log level (although there may be reasons to do things differently on client side). For this reason, a few outputs feel odd here:
You see, my concerns are more about log levels than about output streams. However, both are related. Personally, I'd only use the stderr for actual error information but I also see that stderr could be used for diagnostic information, and you could consider all intermediate log output as such diagnostic information. On the other hand, what we actually may want to have is three different output streams:
Looking at the Bru CLI Overview, this seems to be possible with the bru run folder --output results.json
echo "results.json" | jq So, to make a long story short: I'm not sure whether the proposed changes are necessary or if they add more confusion. Personally, I also like the idea of having the output available as a separate file that I could persist as a pipeline artifact for later inspection. So this actually opens more option for further processing than just being able to pipe the command output into some other command. |
I don't think we should take the name of stderr too literal - I can't think of an application I use that would log warnings to stdout. Kubernetes comes to mind. I am of course aware of the output file option in bruno cli, but it breaks (or hinders) building proper pipelines (see also this answer and the linked article https://stackoverflow.com/a/41766832). Something along the lines of |
Thanks a lot for that link to the Stack Overflow issue! The referenced article was also a good read. Also, Google doesn't really have a suggestion in their Shell style guide. With that in mind, I'm fully with you, although the output file would be a bit redundant as it would basically do the same as redirecting the output to a file. |
I think removing the output file may cause a backwards-incompatibility though. What do you think? Maybe it could be considered for v2 of the cli? |
Yeah, I would not remove it, just accept the redundancy and maybe mark it as deprecated at some point. It doesn't relly make a difference in the end, but for some users it might be more convenient to be able to specify an output file as an argument instead of redirecting the output stream. |
@helloanoop Would you like to weigh in on this? Anything else I/we can do to get those PRs merged? Thanks! :) |
Anything? :) |
Friendly ping :) |
Is there anything I missed? Do I need to follow a different process to get a change merged? |
Anything @helloanoop ? |
Hey @jzorn I had to revert the merge, Need some more time to review this, |
Description
This change moves informational command outputs from console.log (prints on stdout) to console.warn/console.error (prints on stderr) to enable stdout processing in pipelines.
I am not sure how to properly test if this breaks anything, if I have missed anything I am happy to fix any problems.
Fixes #2123
Contribution Checklist:
Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.
Publishing to New Package Managers
Please see here for more information.