Proposal Details
$ go install -list
github.com/goreleaser/goreleaser@v1.26.1
github.com/junegunn/fzf@v0.56.0
golang.org/x/tools/cmd/eg@v0.28.0
golang.org/x/tools/cmd/stringer@v0.28.0
$ go install -drop eg # or golang.org/x/tools/cmd/eg
$ go install -update github.com/goreleaser/goreleaser
go: upgraded github.com/goreleaser/goreleaser => v1.26.2
$ go install -update
go: upgraded github.com/junegunn/fzf => v0.57.0
go: upgraded golang.org/x/tools/cmd/stringer => v0.29.0
An @none version also uninstalls programs, like how go get works:
$ go install golang.org/x/tools/cmd/goimports@none
Comment From: seankhliao
I think we can keep this in #50261
Comment From: willfaught
https://github.com/golang/go/issues/50261 doesn't propose concrete details, so it is unlikely to be considered or get traction. My comment there hasn't been up-voted or responded to positively enough to be considered the de-facto proposal. I think there's merit in keeping both proposals.
Comment From: matloob
Reopening this so we can discuss this proposal individually.
Some questions about this proposal:
* I'm assuming that we get the versions of the binaries by checking their buildinfo? Do we consider a binary to be the "same version" if it doesn't have the same build list as what "go install pkg@version" would produce but does still require the module providing pkg at the same version?
* Is go install -update <pkg> the same as go install <pkg>@latest?
* What does go install -update with no arguments do if the build info of a binary is devel?
I'm a bit uneasy about @none to uninstall programs, because the semantics are different from the usual @none semantics of removing a requirement from the build graph.