cmd/go: explicit '-mod=readonly' argument to go get is not rejected

[kortschak]

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.

[bcmills]

This is working as designed; see #26850 (comment).

[bcmills]

Actually, it might not be in the case of go get: we should probably reject an explicit -mod=readonly to that command.

[kortschak]

Yes, I read @rsc's comment before I filed the issue. Even if it were not an explicit -mod=readonly but rather a GOFLAGS="-mod=readonly" I would think that this behaviour is not what most people would want.

Russ's comment does not explain why go get would 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]

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]

@kortschak, installing a tool without affecting the main module's go.mod file is tracked in #30515.

The problem here is that go get is overloaded to mean two different things: “update my dependencies” and “install a binary”. Without an explicit flag to the contrary, it does both.

The -d flag removes the “install a binary” meaning. #30515 proposes a similar flag to remove the “update my dependencies” meaning.

[gopherbot]

Change https://golang.org/cl/198438 mentions this issue: cmd/go: remove the -mod flag from 'go get'

[kortschak]

@bcmills Riding rough shod is a perfect word for what happened here. Thank you for explaining to me what I meant.