cobra icon indicating copy to clipboard operation
cobra copied to clipboard

Normalize printing to Out vs. Err streams

Open mislav opened this issue 2 years ago • 6 comments

  • Have command.Print*() print to stdout, and print errors & warnings to stderr
  • Deprecate command.OutOrStderr()
  • Handle errors in built-in help command

Warning: backwards-incompatible.

Fixes https://github.com/spf13/cobra/issues/1708

mislav avatar May 24 '22 14:05 mislav

Thanks @mislav. Cobra does have some inconsistencies about printing output. However Cobra being so widely used we have to prioritize backward-compatibility at the expense of standardizing things.

If we ever decided to have a Cobra v2, we would surely standardize the output handling. But moving to a new major version had such a large impact to projects that I would personally prefer avoiding it.

marckhouzam avatar May 24 '22 22:05 marckhouzam

@marckhouzam Thanks for chiming in. And I understand if backwards compatibility is a priority, then it's not a good idea to merge this. Feel free to close; this changeset was mostly meant to complement the referenced issue.

mislav avatar May 25 '22 10:05 mislav

Thank you for taking the time @mislav. I'll check with the other maintainers what we should do with the PR.

marckhouzam avatar May 25 '22 12:05 marckhouzam

Another idea: taking an approach where backwards compatibility is kept, but introducing a new opt-in method that replaces command.SetOut() with a new one that does the right thing. This already happened once in Cobra's history: a method named SetOutput() that handled both out+err streams was deprecated in favor of SetOut() and SetErr().

So for example, we could publish a new method e.g. command.SetOutNonBroken() (final name TBD) and deprecate SetOut in favor of it. What SetOutNonBroken would do is to define the "Out" stream where help text, completion, and version information are written; but keep writing errors and warning messages to the "Err" stream.

mislav avatar May 25 '22 14:05 mislav

Thanks for taking the time to chime in. What is the most conservative change that the maintainers of Cobra would be willing to accept in order to fix the main bug in the referenced issue (deprecation warnings going to the "Out" stream)?

I'm thinking something along these lines: avoid changing the functionality of cmd.Print*(), in case Cobra apps depend on those, but change the internal logic that prints warnings (e.g. deprecation messages) to go straight to ErrOrStderr() instead of using cmd.Print*(). This would technically break apps that depend on deprecation warnings being written to the "Out" stream, but I don't suspect anyone actually relies on that functionality in their apps?

mislav avatar May 30 '22 11:05 mislav

The Cobra project currently lacks enough contributors to adequately respond to all PRs. This bot triages issues and PRs according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the PR is closed. You can:
  • Make a comment to remove the stale label and show your support. The 60 days reset. - If a PR has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening.

github-actions[bot] avatar Sep 07 '22 00:09 github-actions[bot]

The Cobra project currently lacks enough contributors to adequately respond to all PRs. This bot triages issues and PRs according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the PR is closed. You can:
  • Make a comment to remove the stale label and show your support. The 60 days reset. - If a PR has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening.

github-actions[bot] avatar Nov 08 '22 00:11 github-actions[bot]

I'm still interested, though the attached issue has lapsed.

cbandy avatar Nov 14 '22 16:11 cbandy

Per my previous comment, I'm still willing to do this:

What is the most conservative change that the maintainers of Cobra would be willing to accept in order to fix the main bug in the referenced issue (deprecation warnings going to the "Out" stream)?

But I'd like a confirmation from Cobra core team (or person) before I proceed, because I wouldn't like to continue doing work on this if it's going to just get closed by the stale bot (like the referenced issue I opened).

My idea would be to trim down this PR to just bug fixes (e.g. deprecation notices go to "err" stream instead of "out" stream) but leave public APIs the same (i.e. cmd.Print*() set of functions remains unchanged).

mislav avatar Nov 14 '22 18:11 mislav

The Cobra project currently lacks enough contributors to adequately respond to all PRs. This bot triages issues and PRs according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the PR is closed. You can:
  • Make a comment to remove the stale label and show your support. The 60 days reset. - If a PR has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interested in reopening.

github-actions[bot] avatar Jan 16 '23 00:01 github-actions[bot]

I'm interested as well. I support implementing non-breaking changes, and I believe it can be accomplished if the maintainers give their approval. @jpmcb, what are your thoughts on this?

There is one specific task I'd like to perform in my app: adding unit tests to verify the output of stdout/stderr. However, I've noticed that using the SetOut/SetErr methods consistently produces inconsistent results."

tcarreira avatar Jul 18 '23 09:07 tcarreira

The referenced issue got re-opened and in the meantime this PR got outdated, so I'm closing it in favor of the discussion in the issue. There still doesn't seem to be consensus in how this should be solved, so until there is, I don't think there needs to exist a PR that proposes code changes.

mislav avatar Jul 19 '23 06:07 mislav

Thanks for the contribution @mislav and apologies we couldn't get this in.

Yes, let's continue the discussion in the issue.

jpmcb avatar Jul 19 '23 12:07 jpmcb