cmd/go,cmd/distpack: make cmd/gofmt a regular tool

[seankhliao]

gofmt is currently built by cmd/dist and placed in GOROOT/bin/gofmt, next to go.
It could be a tool built on demand, like all the other tools since #71867

This could fix #27166 and shrink the binary distribution size a bit.

cc @golang/go-command

[matloob]

If we do this, would we still have a script that would invoke go tool gofmt in $GOROOT/bin?

[seankhliao]

is it really necessary?

[matloob]

I expect there are users that expect gofmt to be in their PATH after adding GOROOT/bin to their PATH.

But if we decide that we don't need to hold that invariant, that opens up some options: maybe we don't need to add a gofmt tool either. If that's the case, we could integrate cmd/gofmt into go fmt and remove the cmd/gofmt package entirely.

[gabyhelp]

Related Issues

• cmd/go: provide some way to get the gofmt binary path #27166
• proposal: cmd/gofmt: deprecate 'gofmt' in favor of 'go fmt' #33263 (closed)
• cmd/go, cmd/distpack: build and run tools that are not necessary for builds as needed and don't include in binary distribution #71867 (closed)
• cmd/go: `go fmt` should invoke `gofmt` from the current sdk installation #10755 (closed)

Related Code Changes

• cmd/go: run gofmt from current GOROOT

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cherrymui]

I expect there are users that expect gofmt to be in their PATH after adding GOROOT/bin to their PATH.

Yes, people do that. E.g. our git-codereview tool invokes the gofmt command https://cs.opensource.google/go/x/review/+/master:git-codereview/gofmt.go;l=262

Removing the command would break users. If we do this, I think we should we leave a script or a shim binary.

[seankhliao]

maybe we don't need to add a gofmt tool either.

might be harder since some gofmt options aren't exposed through go fmt.
I now see go help fmt says:

To run gofmt with specific options, run gofmt itself.

so we do advertise the availability of it as a standalone command.

[matloob]

I was thinking that if we had the flexibility to remove gofmt from users' PATHs that level of flexibility might also let us change what we offered through go fmt or what's in the documentation. But I think with @cherrymui 's feedback it seems clear that we should keep gofmt in the PATH somehow.

But in that case I still think we should consider other options than making gofmt a tool. Maybe, for example, we can busybox it into the go command so that if the go command is run as 'gofmt' it runs the gofmt main, and then we make gofmt a script that would do that?

[mvdan]

I'll echo what @cherrymui said; gofmt is a very different UI to go fmt. The former works on directories and files, and the latter on packages. I regularly use gofmt across dozens of projects because it lets me format an entire repository, even if it contains multiple Go modules.

I don't oppose having to replace gofmt with go tool gofmt if we can make that transition smooth enough. For example, add go tool gofmt in 1.27, and make gofmt a hard error in 1.29 or 1.30 by e.g. replacing it with a program that fails with a helpful error. I'm not sure if that churn is worth it, though.

I'm not sure I quite follow the ideas to make gofmt a shim script; would that be one of bash/bat/rc depending on the target platform, much like the "make" script for building Go?

[matloob]

I'm not sure what a shim script would look like or if it's possible for to make this change without breaking users that expect it to be present. I guess for me my main concern is that if we're going through the trouble of breaking the expectation that gofmt is in PATH when adding $GOROOT/bin to path we should get enough of a benefit from it, perhaps through reduced binary size or removing redundancy in tools or something else, to make it worthwhile.

[dolmen]

About gofmt being a shim script: when gofmt works from a Go module, it would delegate to the gofmt of the toolchain used in that module.

In fact, I have a more general vision about tools (outside the Go toolchain): I think that all tools outside the Go toolchain should work that way (shim): when they are called from $PATH, they should check if they are working in Go module mode in a Go module and if they are declared as a tool in that module (check output of go tool), and then delegate to go tool <self> if a match is found. I have just filled such a proposal for taskfile.dev.