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

Jump to bottom

cmd/go: go list should not add a dependency to go.mod #37197

Closed
glinton opened this issue Feb 12, 2020 · 3 comments
Closed

cmd/go: go list should not add a dependency to go.mod #37197

glinton opened this issue Feb 12, 2020 · 3 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Unplanned

Comments

@glinton
Copy link

glinton commented Feb 12, 2020 •
edited

Possibly related to #36812
Re-open of #28014 which was not a duplicate of 27643

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

$ go version
go version go1.13.7 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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/me/.cache/go-build"
GOENV="/home/me/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/listTest/go.mod"
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-build352932148=/tmp/go-build -gno-record-gcc-switches"

What did you do?

mkdir /tmp/listTest
cd /tmp/listTest

go mod init test
# go: creating new go.mod: module test

cat go.mod
# module test
# 
# go 1.13

go list github.com/golang/protobuf/proto
# github.com/golang/protobuf/proto

cat go.mod
# module test
# 
# go 1.13
# 
# require github.com/golang/protobuf v1.3.3 // indirect

go mod tidy

cat go.mod 
# module test
# 
# go 1.13

What did you expect to see?

I expected to see if the package argument to go list was present in my go environment. No file writes.

What did you see instead?

I saw that the package argument to go list was present, but I also saw an intrusive update to my go.mod.
@gopherbot
Copy link

Change https://golang.org/cl/219237 mentions this issue: cmd/go: eliminate empty '()' when passing -mod=readonly explicitly to 'go list'

gopherbot pushed a commit that referenced this issue Feb 12, 2020
cmd/go: eliminate empty '()' when passing -mod=readonly explicitly to…
363bcd0 
… 'go list'

Discovered while investigating #37197.

Updates #33326
Updates #34822

Change-Id: I38b136a4ee762a580a554125066b9778491295f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/219237
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@sthagen sthagen mentioned this issue Feb 12, 2020
Merged
@bcmills
Copy link
Contributor

bcmills commented Feb 12, 2020 •
edited

This is closely related to #28692 and #26977, and somewhat more distantly related to #29869.

But the use case here is a bit different from #28692: in that issue, the package mentioned on the command line is in a module already present in the module graph, and go build and go list are just resolving transitive dependencies of that package.

And this use case is also a bit different from #26977: there, go mod why is being asked why a specific package is already in the dependency graph, but here you're explicitly asking go list to tell you about a new package. (If you run go build or go test instead, then probably we should just build or test that package.)

Note that -mod=readonly or -mod=vendor would successfully prevent go list from adding the dependency:

test$ go version
go version devel +363bcd00 Wed Feb 12 18:22:50 2020 +0000 linux/amd64

test$ go mod init test
go: creating new go.mod: module test

test$ cat go.mod
module test

go 1.14

test$ go list -mod=readonly github.com/golang/protobuf/proto
can't load package: cannot find module providing package github.com/golang/protobuf/proto: import lookup disabled by -mod=readonly

test$ go list -mod=vendor github.com/golang/protobuf/proto
can't load package: package github.com/golang/protobuf/proto: cannot find package "." in:
        /tmp/tmp.TideYgX4n4/test/vendor/github.com/golang/protobuf/proto

test$ go list -mod=mod github.com/golang/protobuf/proto
go: finding module for package github.com/golang/protobuf/proto
go: downloading github.com/golang/protobuf v1.3.3
go: found github.com/golang/protobuf/proto in github.com/golang/protobuf v1.3.3
github.com/golang/protobuf/proto

Given that, this seems like a usability question — is it better for go list to resolve the packages that you ask it about, or to reject them if they aren't already in the module graph? But to answer that, we need to examine the context: what was your higher-level goal in running this command? (What led you to run go list for this particular package path without either -mod=readonly or -mod=vendor?)

CC @matloob @jayconrod

@bcmills bcmills added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 12, 2020
@bcmills bcmills added this to the Unplanned milestone Feb 12, 2020
@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Feb 12, 2020
@gopherbot
Copy link

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Mar 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@glinton @bcmills @gopherbot