cmd/go: `go mod graph` doesn't return an error in GOPATH mode

[jeanbza]

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

$ go version
go version go1.12 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

deklerk at deklerk in ~/workspace/go/src/cloud.google.com/go on master*
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/deklerk/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/local/google/home/deklerk/workspace/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/google-golang"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/google-golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build056735032=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go mod graph

What did you expect to see?

go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

What did you see instead?

Nothing. It just returned.

• FWIW GO111MODULE=on go mod graph works as expected.
• FWIW go mod tidy returns the error above as expected.

[andybons]

@bcmills @jayconrod

[iwdgo]

Commands going through LoadBuildList() have a similar behavior in an empty directory.

$export GO111MODULE=auto

$GOPATH/src/mymod>
$ls

$ go mod graph

$ go mod verify
all modules verified
$ go list -m
go list -m: not using modules

The common cause looks like a check on CmdInit as die() always exits with an error message including the one expected.

Removing this check gives all commands a behavior consistent with other go mod commands. The code that follows becomes unreachable in that case.

[bcmills]

@iwdgo, the discrepancy between go mod graph and go list -m is expected: go mod graph asks about all modules (of which there may be none), whereas go list -m asks about a specific one (the main module, which does not exist).

[gopherbot]

Change https://golang.org/cl/174697 mentions this issue: cmd/go: Fix error message for graph in GOPATH mode

[iwdgo]

Here is the behavior on tip of go mod commands.

$GOPATH\src\mymod>ls
sample.go

$GOPATH\src\mymod>set GO111MODULE=auto

$GOPATH\src\mymod>go mod download
warning: pattern "all" matched no module dependencies

$GOPATH\src\mymod>go mod edit -json
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

$GOPATH\src\mymod>go mod graph

$GOPATH\src\mymod>go mod init
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

$GOPATH\src\mymod>go mod tidy
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

$GOPATH\src\mymod>go mod vendor
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

$GOPATH\src\mymod>go mod verify
all modules verified

$GOPATH\src\mymod>go mod why
go: modules disabled inside GOPATH/src by GO111MODULE=auto; see 'go help modules'

With GO111MODULE=off, all commands behave with similar differences:

$GOPATH\src\mymod>go mod tidy
go: modules disabled by GO111MODULE=off; see 'go help modules'

The CL is intended to fix these discrepancies.