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: explicit '-mod=readonly' argument to go get is not rejected #30345

Closed
kortschak opened this issue Feb 22, 2019 · 7 comments
Closed

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

kortschak opened this issue Feb 22, 2019 · 7 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@kortschak
Copy link
Contributor

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

bcmills commented Feb 22, 2019

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

@bcmills bcmills closed this as completed Feb 22, 2019
@bcmills
Copy link
Contributor

bcmills commented Feb 22, 2019

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

@bcmills bcmills reopened this Feb 22, 2019
@bcmills bcmills changed the title 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 Feb 22, 2019
@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. modules labels Feb 22, 2019
@bcmills bcmills added this to the Go1.13 milestone Feb 22, 2019
@kortschak
Copy link
Contributor Author

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

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

bcmills commented Oct 4, 2019

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

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

@kortschak
Copy link
Contributor Author

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

@golang golang locked and limited conversation to collaborators Oct 3, 2020
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants