Installation header output should send to stderr

[matthewnitschke-wk]

A common usage for dpx is to leverage it within github actions to prevent the manual dart pub global activate... step

In this case we always pass -y since it is known that the executable doesn't actually exist, and we want to force install it

When doing this though, the output for installing the package is still emitted:

Need to install the following packages:
Git repository "ssh://git@github.com/...

the major downside of this is if we pipe the output of a command this verbose header is included:

$ dpx -y my_command > out.json
$ cat out.json
Need to install the following packages:
Git repository "ssh://git@github.com/...
{
 "command_json": "here"
}

Thoughts on silencing all command installation output when -y is provided?

[evanweible-wf]

How about updating dpx to write those preamble logs to stderr instead of stdout so that stdout can be redirected independently and won't include any of the noise from dpx itself?

[matthewnitschke-wk]

Unfortunately for my use case, the output I'm trying to capture is actually from stderr (nuance of the current implementation in semver-audit-dart)

Arguably, this is incorrect, and should actually be stdout, but I'm unsure of the downstream changes that adjusting that would be

More generally though, is using stderr for something like that misuse of what stderr is designed to be used for? It is my impression that some executions rely on the output of stederr to determine failure cases

[evanweible-wf]

I think it varies largely because there are only two options to write to, but from what I've seen on the topic, the expected output of a command should go to stdout and everything else (not just errors) should go to stderr. Additionally, I think the exit code should be the primary indicator of whether it failed (and what type of failure it was), not the presence of content on stderr.

The expected output of a command is important here, since it could mean that the same type of content (e.g. help or usage text) goes to a different place based on the command being run. If the user runs dpx --help, they're expecting to receive help output, so it should go to stdout (which would let them pipe it to less, for example). Alternatively, if the user runs dpx --wrong-flag, we might still want to print that same help output, but it should go to stderr because it's no longer intended output of the command, it's an error.

Similarly for the use case in this issue, I'd view dpx -y my_command as a command intended to eventually run my_command. If it isn't already installed, we would install it and (at least as currently implemented) produce some output about that install, but that output isn't a part of the ultimate goal of that command, so it should be on stderr.

Couple of links about this:

• https://stackoverflow.com/questions/2199624/should-the-command-line-usage-be-printed-on-stdout-or-stderr
• https://stackoverflow.com/questions/1068020/app-help-should-go-to-stdout-or-stderr
• https://news.ycombinator.com/item?id=37682859

---

For the suggestion in the original issue description of having -y execute silently, I think I'd rather see us implement some level of logging verbosity control. That way it would still at least be possible to have dpx -y my_command print out information about the install process (could be useful for debugging).

[matthewnitschke-wk]

Huh, seems more murky than I was expecting

I do like this though, seems like a good principal behind the concept

"Well, it's an explicit request for help so it should go to output."

By that logic, I could get behind the installation output sending to stderr