As a user, I would like to have a command that iterates through my $GOBIN and checks if all of the packages I installed are in their latest version. the new go install command is great and allows installing the binaries without changing anything on the machine.

some solutions I can see in mind for this: 1. have a similar solution of go.mod or a section inside go.mod that relates to binaries so go list can display them and then can be easily iterated on. 2. create a new go_install.mod specific for this solution 3. add metadata in the $GOBIN folder on what binary version was installed and the go install will read it when using the --list-outdated flag 4. other

this issue comes from the fact I have an update command that upgrades all of the components on my machine fairly frequently and rust has https://github.com/nabijaczleweli/cargo-update for that case

Comment From: georgettica

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

Comment From: kortschak

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

Comment From: georgettica

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

I'll try it out and report back 😀

Comment From: beoran

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

Comment From: georgettica

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

Comment From: georgettica

@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.

Comment From: phanirithvij

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

Comment From: georgettica

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

Comment From: mvdan

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.

Comment From: vikblom

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).

Comment From: willfaught

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

Comment From: kortschak

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

Comment From: bjorndm

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.

Comment From: matloob

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.