Skip to content
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.

Sign up for GitHub

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

Jump to bottom

cmd/go: should go list -json imply -e? #30755

Open
marwan-at-work opened this issue Mar 12, 2019 · 5 comments
Open

cmd/go: should go list -json imply -e? #30755

marwan-at-work opened this issue Mar 12, 2019 · 5 comments
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@marwan-at-work
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go 1.12 darwin

Does this issue reproduce with the latest release?

Yes

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
@bcmills
Copy link
Contributor

bcmills commented Mar 12, 2019

Is that on stdout, or on stderr?

(See previously #26218 (comment).)

CC @jayconrod

@jayconrod jayconrod self-assigned this Mar 12, 2019
@jayconrod jayconrod added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Mar 12, 2019
@marwan-at-work
Copy link
Contributor Author

marwan-at-work commented Mar 12, 2019 •
edited

@bcmills stderr 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).

For example

GO111MODULE=on go mod download -json github.com/golang/nonexistentrepo@latest

returns

{
	"Path": "github.com/golang/nonexistentrepo",
	"Version": "latest",
	"Error": "invalid version \"latest\""
}

@bcmills
Copy link
Contributor

bcmills commented Mar 28, 2019

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?

@bcmills bcmills changed the title cmd/go: go list -json does not return json on error cmd/go: should go list -json imply -e? Mar 28, 2019
@marwan-at-work
Copy link
Contributor Author

marwan-at-work commented Apr 2, 2019 •
edited

From a consistency standpoint, it makes sense to have go list -m -versions imply -e since go mod download -json certainly implies -e (even though it doesn't have an -e flag to begin with).

I'm not sure about other go commands so it might be worth a scan.

Thanks!

@rsc
Copy link
Contributor

rsc commented Apr 9, 2019

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.

@seankhliao seankhliao mentioned this issue Jun 2, 2021
Closed
@jayconrod jayconrod removed their assignment Oct 14, 2021
@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @jayconrod @bcmills @seankhliao @marwan-at-work