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.

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

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

Closed
jadekler opened this issue Apr 3, 2019 · 5 comments
Closed

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

jadekler opened this issue Apr 3, 2019 · 5 comments

Comments

@jadekler
Copy link
Contributor

@jadekler jadekler commented Apr 3, 2019

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 andybons changed the title `go mod graph` doesn't return an error cmd/go: `go mod graph` doesn't return an error Apr 3, 2019
@andybons andybons added this to the Unplanned milestone Apr 3, 2019
@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Apr 3, 2019

@bcmills bcmills changed the title cmd/go: `go mod graph` doesn't return an error cmd/go: `go mod graph` doesn't return an error in GOPATH mode Apr 12, 2019
@bcmills bcmills modified the milestones: Unplanned, Go1.13 Apr 12, 2019
@iWdGo

This comment has been minimized.

Copy link
Contributor

@iWdGo iWdGo commented Apr 29, 2019

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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Apr 30, 2019

@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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 1, 2019

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

@iWdGo

This comment has been minimized.

Copy link
Contributor

@iWdGo iWdGo commented May 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.