Open weikanglim opened 2 years ago
Another more obvious issue that indicates we need to do something:
Our current logic on detecting whether we should be printing interactive output is interactive := formatter.Kind() == output.NoneFormat
. This is different than az cli
where output == None
means nothing except for errors and warnings: https://docs.microsoft.com/en-us/cli/azure/format-output-azure-cli
Our NoneFormat
does not mean "no output", it means "data will be outputted in default/natural format". So it is a different concept from the one that az CLI has. Feel free to propose a better name for ours.
The original Unix design is that stdout is for data, and stderr is for human interaction (not just errors!). Unfortunately, that design has not been followed as it should have been, and lots of programs dump a mix of data and messages to stdout (or assume that if something appears on stderr, that alone means an error occurred). But that does not mean we shouldn't do the right thing.
This means, when --output json
is set:
@jongio @savannahostrowski Doesn't seem to be a must-fix for our next milestone. Moving it to On Deck for now.
Wei noticed that we are somewhat inconsistent on where we write error output. When we address this issue we would try to fix that as well.
If
azd
is intended to be consumed by other software/tooling as part of automation, we need to produce predictable clean output as part of some well-defined contract.For example, perhaps we intend that any software tooling that consumes
azd
should pass--output json
for a deterministic output. If so, anytime a command has--output json
format specified, the only output logged tostdout
should either be:Info/warning messages that are emitted as part of the command that would usually serve to provide user feedback should be suppressed.
If we can define this logic cleanly, we would be able to increase user feedback where needed without breaking contracts for software consumers. An example would be a login attempt message that occurs with all commands, but only when allowed.
This would also be a chance to clean up existing output where we might have muddied the contract for a software consume. For example, currently parsing the result of
azd version
might be problematic whenazd
is out-of-date, and additionalstdout
output message is generated for the version warning: