this could also make the vim-go binary installation simpler
https://github.com/fatih/vim-go/blob/585e12d32b3a1defcf863bd405b440cefbd4e31a/plugin/go.vim#L78

This can be done with external tooling, for example https://github.com/kortschak/ugbt/.

Searched external tooling for a while and didn't find this.

I'll try it out and report back 😀

If go clean -i does not do this already then it should.

I forgot to report back. the tool works great!
collaborated with @kortschak on it and created https://github.com/georgettica/ugbt-update-all-gobin to accomodate my own needs

@beoran not sure how your comment is related to the issue, but if you meant:

go clean -i ${GO_REPO_NAME}@${GO_REPO_VERSION}

for deleting what was installed via gobin it didn't work.

Found one https://github.com/nao1215/gup (an external tool)

not as heavy into go binaries now, but if others think that gup is more mature than ugbt I'll switch my stuff there

I thought I'd add my 2c to this issue: I have a script that reinstalls a set of tools I use regularly at their latest (or master/main, depending on each case) versions. It's much dumber than the other kinds of automatic tools proposed here, but I'm fine with that. Every now and then I'll delete my entire GOBIN, so any tools that I installed once and miss, I add to the script so they are reinstalled and kept up to date.

I think it would make sense if go install could manage and keep programs at least up to date, both in terms of source code and compiled-with version.

I have my own program that does what I expect gup and other tools are doing. Loop over programs in $GOBIN and work with the version info the compiler puts in binaries (since a while back).

It would be nice to have something like:

$ 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

It seems like go install should install the latest version when no version is specified, like how go get works with dependencies:

$ go install golang.org/x/tools/cmd/goimports # v0.29.0 installed

It seems like an @none version should uninstall programs, like how go get works with dependencies:

$ go install golang.org/x/tools/cmd/goimports@none # golang.org/x/tools/cmd/goimports@v0.29.0 uninstalled

This conflates the role of the go tool (as a collection of compiler tools) with a package manager.

With go mod that ship already has sailed. Ten years ago the go command only was a compiler. Now the go command also includes a module manager, and go install is a binary manager.

We should leave this to external tools. The go command does have a module system, and I do think it makes sense to manage things on a module level: the user defined tool support in Go 1.24 is a nice way to do that. But there is a mismatch between the module system and the global nature of GOBIN and I think it would be hard to bridge that.

For example, it's not clear what we do when the binaries in GOBIN were not built using "go install pkg@version", and it's a bit complex to determine when that is the case. For example, does the build graph have to be exactly the same, or is it okay if the build was done from a module where the required version of the module providing pkg was version?

I think there's a (only slightly awkward) way to manage global tools using the tool support: You could create a new go.mod for a module that's only meant to manage these binaries and run go get -tool for each of the binaries you want to manage. Then go get tool would update all the requirements for tools in the go.mod and go install tool would install those tools. This wouldn't work quite the same way as @willfaught's proposed go install changes: the biggest difference is that all these tools would share a module graph, so the build could be different from using go install pkg@version for each of the binaries. But also there would also be no concept of uninstalling a tool (I think that's another problem that's a bit unclear).

I'm going to close this issue, but I don't want to completely rule this out. I do think that we should discuss specific proposals in new issues that are created for them. I'll re-open #71351 as one of those specific proposal issues.