You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
cmd/go: deprecate installing binaries using 'go get' in Go 1.17 and make 'go get -d' the default behavior #43684
Proposal #40276 added a versioned go install variant that works outside of a module.
As part of the changes approved in that proposal, we plan to deprecate the use of the go get to install binaries, and make go get -d (which downloads source code for but does not build the requested packages) the default behavior.
We had planned to warn about the use of go get to install binaries in Go 1.16 and make it the default in Go 1.17. However, in #42885 we decided to also delay the warning until Go 1.17, so that third-party projects that support the most recent two major Go releases (as the Go project itself does) can give users a single non-deprecated install command, rather than a confusing menu of commands that vary by Go version.
I don't see an issue filed yet to track that change in Go 1.17, so this is that tracking issue. (CC @jayconrod@matloob)
It is not clear to me whether we should print a deprecation notice in Go 1.17 and change the default behavior in Go 1.18, or change the default behavior in 1.17 and merely print a notice informing the user of the change if their go get pattern happens to match a package main.
As part of the changes approved in that proposal, we plan to deprecate the use of the go get to install binaries, and make go get -d (which downloads source code for but does not build the requested packages) the default behavior.
I‘m all for this. Its a regular source of confusion that go get fails when I pull the sources for later cross-compile and the go get fails with architecture-specific error messages.
change the default behavior in 1.17 and merely print a notice informing the user of the change if their go get pattern happens to match a package main.
The sooner the better. Just add a short instruction for the non-Go user stumbling upon older source that "Since Go 1.17 to install an app from the source you need to use go install instead of go get". I'd also suggest adding the -u flag to the install - silent or with a compact message that "-u is not needed with install".
Activity
bcmills commentedon Jan 14, 2021
It is not clear to me whether we should print a deprecation notice in Go 1.17 and change the default behavior in Go 1.18, or change the default behavior in 1.17 and merely print a notice informing the user of the change if their
go getpattern happens to match apackage main.ianlancetaylor commentedon Jan 14, 2021
bcmills commentedon Jan 14, 2021
andig commentedon Jan 14, 2021
I‘m all for this. Its a regular source of confusion that go get fails when I pull the sources for later cross-compile and the go get fails with architecture-specific error messages.
luantak commentedon Jan 17, 2021
bcmills commentedon Jan 17, 2021
gopherbot commentedon Feb 24, 2021
This issue is currently labeled as early-in-cycle for Go 1.17.
That time is now, so a friendly reminder to look at it again.
ohir commentedon Feb 27, 2021
The sooner the better. Just add a short instruction for the non-Go user stumbling upon older source that "Since Go 1.17 to install an app from the source you need to use
go installinstead ofgo get". I'd also suggest adding the -u flag to the install - silent or with a compact message that "-u is not needed with install".dmitshur commentedon Mar 25, 2021
Friendly ping @bcmills, @jayconrod, @matloob since this is a release blocking issue and has an early in cycle label.
gopherbot commentedon Mar 30, 2021
Change https://golang.org/cl/305670 mentions this issue:
cmd/go: print deprecation notice for 'go get cmd'52 remaining items
_content: change 'go get' to 'go install' where appropriate
cmd/go: adjust documentation mentioning 'go get'
gopherbot commentedon Oct 12, 2021
Change https://golang.org/cl/355493 mentions this issue:
cmd/go: stamp tags and flags in build infogopherbot commentedon Oct 21, 2021
Change https://golang.org/cl/357714 mentions this issue:
all: update install commands to go install pkg@versionall: update install commands to go install pkg@version
_content/doc: add a page explaining 'go get' deprecation
_content/ref: add extra note for 'go get' build deprecation
_content/doc: update multiple go install instructions
_content/doc/contribute: use 'go install' instead of 'go get'
_content: change 'go get' to 'go install' where appropriate
doc/go1.17: note deprecation of 'go get' for installing commands