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
jeanbza opened this issue Apr 3, 2019 · 5 comments
Closed

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

jeanbza opened this issue Apr 3, 2019 · 5 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@jeanbza
Copy link
Contributor

jeanbza 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 modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 3, 2019
@andybons andybons added this to the Unplanned milestone Apr 3, 2019
@andybons
Copy link
Member

andybons commented Apr 3, 2019

@bcmills @jayconrod

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

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

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

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

@iwdgo
Copy link
Contributor

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants