Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: consider including Go's own version in 'go env' #41116

Open
mvdan opened this issue Aug 28, 2020 · 3 comments
Open

cmd/go: consider including Go's own version in 'go env' #41116

mvdan opened this issue Aug 28, 2020 · 3 comments

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Aug 28, 2020

go env -json tells me a lot about the user's Go setup and environment, and in a format that's easy to parse. Unfortunately, go version is missing there, so if I want to fetch that I need a separate exec call.

I wonder if we could add it to go env, similar to other "not really an env var" lines like GOMOD, GOEXE, or GOHOSTARCH. For example:

$ go version
go version go1.15 linux/amd64
$ go env -json
[...]
    "GOVERSION": "go1.15",
[...]

It would not include the string prefix go version, since it's redundant, nor the linux/amd64 pair, since that's already as GOHOSTOS/GOHOSTARCH in go env.

I'm not making this a proposal for now, since the idea seems pretty simple.

/cc @bcmills @jayconrod @matloob for cmd/go

@ainar-g
Copy link
Contributor

@ainar-g ainar-g commented Aug 29, 2020

I'm very in favour of this. When I'm debugging builds on a remote machine or helping a colleague, I call go env and go version in tandem. Even the default issue template here on GitHub requires the output of both commands.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Aug 29, 2020

That's a good point; just having to call go env would be pretty handy when debugging problems on other machines.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Sep 23, 2020

On our last golang-tools call, @bcmills, @jayconrod, and @heschik raised a good point. The version reported by go version isn't the only interesting bit of information from the Go toolchain that tools would find useful. There's also the "Go language version" or major version used for build tags such as // +build go1.15. For the sake of clarity, let's call those GOVERSION and GOMAJORVERSION.

At the time of writing, if one runs Go 1.15.2, one could imagine:

$ go env
[...]
GOVERSION="go1.15.2"
GOMAJORVERSION="go1.15"

That seems simple enough. In the case of a stable release, they'll always share the first two semver components. However, it gets more interesting for devel builds. For example, with my current master build, as per src/internal/goversion/goversion.go showing const Version = 16:

$ go env
[...]
GOVERSION="devel +150bd4ffd4 Wed Sep 23 07:51:17 2020 +0000"
GOMAJORVERSION="go1.16"

We could bikeshed about the names, but it seems clear to me that both versions are useful to have, and they're clearly different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.