cmd/go: list module@version should suggest -m flag

[seankhliao]

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

$ go version
go version devel go1.18-bb7fb8a5fa Wed Jan 19 21:46:55 2022 +0000 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/arccy/.cache/go-build"
GOENV="/home/arccy/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/arccy/.data/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/arccy/.data/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/arccy/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/arccy/sdk/gotip/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.18-bb7fb8a5fa Wed Jan 19 21:46:55 2022 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4196401972=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go list -f '{{ .Version }}' miniflux.app@686dd92cb9e486c41f407e93d2e10f6b4609f778
package miniflux.app@686dd92cb9e486c41f407e93d2e10f6b4609f778: can only use path@version syntax with 'go get' and 'go install' in module-aware mode

What did you expect to see?

An error message telling me I may have wanted go list -m ...

What did you see instead?

Error message only mentions go get and go install

cc @bcmills @matloob

[AGMETEOR]

Hello there @bcmills. I would like to work on this.

[gopherbot]

Change https://golang.org/cl/381195 mentions this issue: cmd/go: better error message for when line having '@'

[matloob]

Echoing bcmills' comment on CL 381195, it seems like just adding go list -m will end up in us getting an overly long list in a context where none of the commands might be what users want (especially when we'll also have to add go run pkg@version if we want to cover all the cases).

We should have a discussion here about what we want the error to be before we proceed. @seankhliao What do you think?

[seankhliao]

tbh I'm not sure why this command can't just work

as for the error message, would it be unreasonable to not list commands in the base error, and check for the error type at call sites? from memory go list and go mod why are the common operations that trip people up over requiring -m for modules

[matloob]

as for the error message, would it be unreasonable to not list commands in the base error, and check for the error type at call sites? from memory go list and go mod why are the common operations that trip people up over requiring -m for modules

I think this could be done, but it would take some work to figure out how to do the checking in a "clean" way. The error is currently stored on the package and then the build/list commands check the errors on all the packages and exit (in most circumstances, for example if not list -e) if there's an error. We'd have to figure out the right way to check the errors and act on them properly.