cmd/go: deprecate the -i flag

[jayconrod]

go build, go install, and go test accept the -i flag. From go help build:

The -i flag installs the packages that are dependencies of the target.

For example, if you run go build -i example.com/a, and example.com/x imports example.com/y, go build installs the file $GOPATH/pkg/$GOOS_$GOARCH/example.com/y.a.

This was useful for speeding up builds before Go 1.10, since previously installed packages didn't need to be recompiled. go build re-used packages installed in $GOPATH/pkg.

Go 1.10 introduced the build cache, so the $GOPATH/pkg directory is largely obsolete. Compiled packages are now stored in $GOCACHE. The -i flag merely copies files out of the build cache, so there's no longer any performance advantage.

The -i can cause errors when a target directory is not writable, as in #37962. In that issue, VSCode installed tools with -i, which caused errors when $GOROOT/pkg was not writable (common when Go is installed system-wide with an installer). Something caused runtime/cgo to be recompiled (perhaps a new clang version or flag), but it couldn't be written to $GOROOT/pkg/darwin_amd64/runtime/cgo.a.

Because of these problems, we should consider deprecating and eventually removing the -i flag.

[jayconrod]

cc @bcmills @matloob @rsc

[rsc]

Are there any objections to doing this? I see plenty of emoji in favor and nothing else.

[mvdan]

My only potential objection is breaking people who learned to use go build -i years ago, and perhaps introduced the flag in build or CI scripts. So the eventual removal of support for -i should come with a clear deprecation warning in the release changelog at least one or two releases before then.

[rsc]

@mvdan, yes, deprecate and remove means it will have a release of printing a warning that -i is going away followed by the actual removal in the next release.

[rsc]

Based on the discussion above, this seems like a likely accept.
To be clear, Go 1.16 would warn that the flag should not be used (but still complete successfully), and Go 1.17 would remove the flag.

[rsc]

No change in consensus, so accepted.

[gopherbot]

Change https://golang.org/cl/266368 mentions this issue: cmd/go: print deprecation messages for -i

[gopherbot]

Change https://golang.org/cl/268581 mentions this issue: cmd/go: update test_race_install expected output for CL 266368

[mvdan]

It just occurred to me that sometimes I still used go test -i -v ./... to see what packages were being built in advance of running tests.

I guess I can move to go test -run=- -v ./... nowadays, but I thought I'd point that out as a reasonable use case.

[bcmills]

@mvdan, is there a way to use the -c flag to get the information you want?

(Perhaps go test -c -v -o /dev/null ./...?)

[mvdan]

Doesn't seem like I can use -c with many packages at once, which makes sense.

For clarity, what I liked about go test -i -v ./... is that I could see the stream of packages being built. This is useful if go test ./... suddenly seems to take a long time to start running tests, for example after someone adds a large cgo dependency like go-sqlite3. Seeing the stream of packages being built, one would see the progress stuck at that package for more than ten seconds, which is a pretty clear signal.

But maybe there are better ways to inspect what's being a bottleneck in a Go build :) There's go list -test -deps ./..., but that simply lists packages, it doesn't perform a build or tell me what packages are the slowest to build.

go list -test -export -v ./... is pretty close, though; -export means building the packages, -test pulls in test deps, and -v prints packages as they are being built.

[bcmills]

But maybe there are better ways to inspect what's being a bottleneck in a Go build

Maybe -debug-trace (#38714)?

[gopherbot]

Change https://golang.org/cl/322629 mentions this issue: cmd/go,cmd/link: do not check for staleness in most tests

[gopherbot]

Change https://go.dev/cl/416094 mentions this issue: cmd/go: remove -i build flag

[gopherbot]

Change https://go.dev/cl/449075 mentions this issue: doc/go1.20: add release notes for cmd/go changes