Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: add GOCMD environment variable #28043
Tools for interacting with go code need to exec the go command. Sometimes there are multiple versions of the go command available, rarely themselves named "go": go, vgo, go1.1xbetax, go1.1x, etc.
Tools that exec "go" cannot use these without $PATH manipulation and shell scripts named "go" that forward to the desired go command. Possible, but awkward.
This should be the convention:
If this environment variable were not known to the go command itself, this would be required:
By showing up in
If it is official,
Previous discussion in #26845
It's true that it's one more thing for most people to skip over in the docs.
The people with multiple go commands are largely the ones testing/developing future versions of Go, running CI/CD against multiple versions of Go, or writing the tools that everyone uses.
Moreover, the go commands that are not named go largely come from the Go project itself to try to make it simpler to help test changes. It would be nice to also have a simple way to access tools while doing that, which in turn makes it more likely for a regression in a tool to be found
That is me - I develop / debug Go. I do not need new GOCMD environment variable. I am doing just fine as is.
Having new GOCMD environment variable is not free. Someone would havve to document it, and keep documentation updated. Someone would have to educate users about GOCMD variable. Someone would have to debug problems related to GOCMD environment variable. And so on ...
Everything you say is true. But I still think this is worth it.
This solves a lot of issues transparently and when it doesn't it makes them much more easily solvable than they are currently. And I think these issues are going to become more common as go/packages becomes more common as more tools are going to be execing go in the background (though they should have been doing so anyway).
Even if that's not a problem for you, a frequent contributor for a long time, or for me, an occasional contributor for a much shorter time, it's going to be a problem for the user who decided to go the extra mile and try a beta for the first time and can't figure out why
There's also a cost to losing eyes and to having to explain the current workarounds.
Note that internally we have a package called
Tooling needs to exec the go command, to get information from
If they always invoke the literal string "go", and you're working in a project using
Working on Go itself is simpler because you can just change your path. The go command at tip is still named go.
The tests for the go command can make an assumption that their runtime.GOROOT is correct. In general the only way for an external tool to reliably find the go root is to exec
When I was trying out modules with
The same problem comes up with the beta releases and the
@mvdan $PATH is fine, if a bit awkward, when the alternate go command is named go.
It's more involved when it's not named go. If you grab a beta the binary is already going to be in the path but it's going to be named something like
To use that with tools that exec "go", you need to write a script named "go" that runs that particular go command and add that to your path. If you have multiple alternate go commands you need to do this for each. It looks more like
That's a lot of bookkeeping for what's supposed to be the "easily try things out" version.
You don't have to do that to use the
Say you're writing a small program to try out a new function in the next version of the stdlib. You want to run you favorite linter. It involves type checking. It's going to fail because it execs
That linter could support the
But the same problem comes up if you want to use generate and the tool that does the generation execs go. You have to stutter and do
The major benefit of having it be an official environment variable is standardization. That avoids having to sometimes set
@jimmyfrasche, it seems like we could address your
For other cases,
PATH=$(go1.12beta1 env GOROOT)/bin:$PATH some-tool-that-execs-go-list
I agree with Bryan that there are ways to address this without new mechanisms; you could even run vgo if you put a link to it named