Repository navigation
cmd/go: explicit '-mod=readonly' argument to go get is not rejected #30345
Description
What version of Go are you using (go version)?
$ go version go version go1.12rc1 linux/amd64
Does this issue reproduce with the latest release?
Above is release candidate.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env go version go1.12rc1 linux/amd64 ~/src/github.com/mdempsky $ go env GOARCH="amd64" GOBIN="" GOCACHE=".../.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="..." GOPROXY="" GORACE="" GOROOT=".../go" GOTMPDIR="" GOTOOLDIR=".../go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" 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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build909675092=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Change directory into a go.mod-containing project with no requirement for "path/to/main". GO111MODULE=on go get -mod=readonly path/to/main, where the executable at path/to/main is a tool that I want once and not as a dependency for the project, or I want as a developer and not a user of the project.
What did you expect to see?
No change to go.mod file.
What did you see instead?
Addition of "path/to/main" as a requirement in go.mod.
I understand that the docs say that 'The "go get" command remains permitted to update go.mod even with -mod=readonly;. However in this situation there should be some way of not polluting the go.mod just because I happen to be in a module.
The current behaviour is equivalent requiring that I always need to have my car keys on me in the kitchen because at one stage I thought to go and get my car keys when I was in the kitchen, or that a 40lb mallet is required in the kitchen because there was a builder there using one once.
Activity
bcmills commentedon Feb 22, 2019
This is working as designed; see #26850 (comment).
bcmills commentedon Feb 22, 2019
Actually, it might not be in the case of
go get: we should probably reject an explicit-mod=readonlyto that command.[-]cmd/go: go get for main packages updates go.mod when in module mode and -mod=readonly[/-][+]cmd/go: explicit '-mod=readonly' argument to go get is not rejected[/+]kortschak commentedon Feb 22, 2019
Yes, I read @rsc's comment before I filed the issue. Even if it were not an explicit
-mod=readonlybut rather aGOFLAGS="-mod=readonly"I would think that this behaviour is not what most people would want.Russ's comment does not explain why
go getwould want to behave the way that it currently does with an explicit flag or with an envvar saying the same thing. Certainly not with a flag/var that says read only. Maybe that name could have had more thought.kortschak commentedon Feb 22, 2019
Just re-reading the change of issue title now, it seems that the intended solution is to just not allow a user to pass that flag. I don't see how not listening is going to help the actual use case problem that caused this issue to be raised.
bcmills commentedon Oct 4, 2019
@kortschak, installing a tool without affecting the main module's
go.modfile is tracked in #30515.The problem here is that
go getis overloaded to mean two different things: “update my dependencies” and “install a binary”. Without an explicit flag to the contrary, it does both.The
-dflag removes the “install a binary” meaning. #30515 proposes a similar flag to remove the “update my dependencies” meaning.gopherbot commentedon Oct 4, 2019
Change https://golang.org/cl/198438 mentions this issue:
cmd/go: remove the -mod flag from 'go get'kortschak commentedon Oct 4, 2019
@bcmills Riding rough shod is a perfect word for what happened here. Thank you for explaining to me what I meant.