cmd/go: deprecate installing binaries using 'go get' in Go 1.17 and make 'go get -d' the default behavior #43684
Comments
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 |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
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. |
This comment has been minimized.
This comment has been minimized.
This comment has been hidden.
This comment has been hidden.
This issue is currently labeled as early-in-cycle for Go 1.17. |
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 |
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 makego 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)
The text was updated successfully, but these errors were encountered: