-
Notifications
You must be signed in to change notification settings - Fork 18.5k
Description
go list -json is very useful, because it makes its output very easy to consume by other programs. Its companion, go list -f, is almost equally as useful for similar cases, such as when one needs just one field, or when one is calling the Go tool from a shell script, where JSON decoding isn't as straightforward.
So, for instance, I can obtain the current package's import path via just go list -f {{.ImportPath}} rather than reaching for an external tool like go list -json | jq -r .ImportPath.
I argue that a similar situation applies to go mod edit -json; it's a great way to obtain the data contained by go.mod files without needing to use a parser that understands its syntax. However, we lack a go mod edit -f, so if I want to obtain just one field like {{.Go}}, I have to reach for a JSON parser.
I think it would be relatively straightforward to add go mod edit -f, and it would make the command more consistent with go list -f.
One potential argument against this proposed flag addition is that we already have other cmd/go commands that have a -json flag, but no -f flag. One by one, and excluding go mod edit, these are:
go work edit: arguably the same case asgo mod edit, and should be changed as wellgo test -json: it prints a newline-separated stream of JSON objects, and it tends to print a lot more output, so a proper program with a JSON parser is a reasonable requirementgo env -json: it's already easy to get a single value without JSON encoding viago env NAME, sogo env -f {{.NAME}}feels redundant