Does this issue reproduce with the latest release?
What did you do?
GO111MODULE=on go list -m -versions -json github.com/golang/nonexistentrepo@latest
What did you expect to see?
A valid json output with a clear error in the Error field. Something similar to when go mod download has an error as such:
"Error": "repository not found"
What did you see instead?
A non json output as such (modified):
go list -m github.com/golang/nonexistentrepo: git ls-remote -q origin in /Users/me/go/pkg/mod/cache/vcs/xxx-long-sha: exit status 128:remote: Repository not found.fatal: repository 'https://github.com/golang/nonexistentrepo/' not found
The text was updated successfully, but these errors were encountered:
@bcmillsstderr I believe. Regarding the comment you linked, with the same exact "error" go mod download has an almost opposite behavior: nothing logged to stderr, and you get a valid json with an Error field inside of it. Though the error field is inaccurate (different, but related issue).
GO111MODULE=on go mod download -json github.com/golang/nonexistentrepo@latest
"Error": "invalid version \"latest\""
If the non-JSON output is going to stderr, then the behavior may be unfortunate but it is not a bug. Tools that expect structured output must separate stdout from stderr.
go list -e -m -versions -json github.com/golang/nonexistentrepo@latest should certainly suppress the stderr output and place the error in the Error field instead, but it isn't at all obvious to me whether that behavior is appropriate without the -e flag.
Does -json imply -e for other kinds of errors in general?
Most people using go list -json should also add -e.
The first problem is that -e does not do everything it should right now.
Let's fix that.
I am not 100% sure that -json without -e is so useless that it should be disallowed entirely.
It seems better to keep them orthogonal.
Even if -json reported errors in JSON, you might still prefer
to not say -e so that you can get an exit code about overall success.