Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x/dl: add versioned gofmts #26397
It is well understood that users shouldn't enforce Go source code formatting
The reason is simple - the formatting that the package produces depends on the
When a project wants to enforce gofmt, what they should instead do is
However, it can be difficult for many systems and developers to run exactly the
Currently, it isn't easy for those people to download a specific version of
This proposal suggests to add a similar mechanism to install a specific version
Then, one could write a pre-commit hook to enforce
This is slightly possible already:
It is, and I believe I noted it in the proposal, but it's not as good of a solution. From my 1.10 install,
If someone needs a development environment on Go version X, I agree that they should install that instead of downloading tools like
Here's a slightly different idea: instead of
At proposal review we are a bit confused about the use case here. It's no good to use this to reach backward in time and grab older gofmts, since in general new syntaxes can be added to go that those gofmts won't handle (the last I remember was
You could potentially reach into the future and grab the latest gofmt before everyone's dev environments was using it. So maybe you'd force use of Go 1.11 gofmt even if your dev machines were not using Go 1.11. But why are the dev machines on different Go versions?
It's certainly overkill to download 300MB to get a 4MB binary. And we could with some effort maintain a special repo of versioned gofmt commands. But why? How would these get used? What problem would they solve? That's what we don't quite understand.
I agree that using an older gofmt than the latest Go stable version makes little sense. And I agree that, in general, all developers should be using the latest stable version of Go.
However, there are still a few scenarios where being able to download the latest stable version of gofmt would be useful. I briefly mentioned a couple in my original post, but I'll expand on some that I encountered recently.
I realise that these cases are all about convenience rather than an absolute need. Then again, I imagine that
Perhaps @thaJeztah or others have other use cases for this.
Talked to @bradfitz and @griesemer. It sounds like we agree with adding subdirectories gofmt1.9, gofmt1.10, etc, to the dl repo, so that you can go get golang.org/x/dl/gofmt1.10, even if you are using Go 1.9. (This would mean that go/parser etc would need to wait two cycles before using new features. They tend to be very plain Go and not change often, so that shouldn't be too onerous. It's less onerous than the compiler requirement (keep working with Go 1.4).)
Each subdirectory would build against its own copies of the relevant libraries so "golang.org/x/dl/gofmt1.10/internal/go/parser", etc. A script in the dl repo would automate copying them out of the Go release, updating imports, and so on. At each release we should only have to run "./addgofmt go1.10".
A README or doc comment (perhaps in each subdirectory) should make clear that it's best to use newer gofmt on old Go source; old gofmt on new Go source is not guaranteed to work and is likely not to.
Any interest in doing this, @mvdan?
referenced this issue
Sep 9, 2018
Thanks for the update, and apologies for the late reply - been travelling a bit the past month.
Only having old
Perhaps we could label this issue as "help wanted" and see if someone is willing to put in the work. If noone pops up in a few months, I'd personally be fine with rejecting the proposal - after all, that may be a sign that the issue isn't as widespread as I thought.