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

proposal: cmd/go: add go version -json #55136

Closed
willhughes-au opened this issue Sep 19, 2022 · 11 comments
Closed

proposal: cmd/go: add go version -json #55136

willhughes-au opened this issue Sep 19, 2022 · 11 comments
Milestone

Comments

@willhughes-au
Copy link

Background

Issue #21207 describes an effectively similar problem, but was closed without actually resulting in a structured version output.

Problem

When using CI Tools and pipelines, it is often required to know the major/minor version of Go.

Not least of which for passing into go commands such as go mod tidy which has a -compat argument, which requires just the major.minor version number.

Current Work-Arounds

As best as I can tell, everyone seems to be using some kind of regex against the output of go version.

Proposal

An argument for go version which will output a structured format of some kind, or perhaps just the version elements requested.

@gopherbot gopherbot added this to the Proposal milestone Sep 19, 2022
@ianlancetaylor ianlancetaylor added the GoCommand cmd/go label Sep 20, 2022
@ianlancetaylor
Copy link
Contributor

CC @bcmills @matloob

@mvdan
Copy link
Member

mvdan commented Sep 20, 2022

You're somewhat there already via go env -json. For example:

$ go1.18.5 version
go version go1.18.5 linux/amd64
$ go1.18.5 env -json GOVERSION GOOS GOARCH
{
	"GOARCH": "amd64",
	"GOOS": "linux",
	"GOVERSION": "go1.18.5"
}

or with tip:

$ go version
go version devel go1.20-1eeb257b88 Tue Sep 20 02:58:09 2022 +0000 linux/amd64
$ go env -json GOVERSION GOOS GOARCH
{
	"GOARCH": "amd64",
	"GOOS": "linux",
	"GOVERSION": "devel go1.20-1eeb257b88 Tue Sep 20 02:58:09 2022 +0000"
}

@willhughes-au
Copy link
Author

willhughes-au commented Sep 29, 2022

@mvdan Thanks for pointing out the -json args and options, however GOVERSION still requires parsing out the actual version numbers from the returned text. Perhaps more options could be added for the major, minor and point version (or use whatever terms that Go normally uses)?

Perhaps for tip/non-official releases there could be another option for what git rev it was built from or something like that.

For example, to take your two examples, it would be good to have these values output independently.

$ go1.18.5 env -json GOVERSION GOOS GOARCH GOMAJORVERSION GOMINORVERSION GOPOINTVERSION
{
	"GOARCH": "amd64",
	"GOOS": "linux",
	"GOVERSION": "go1.18.5", 
        "GOMAJORVERSION": 1, 
        "GOMINORVERSION": 18,
        "GOPOINTVERSION": 5
}

and

$ go env -json GOVERSION GOOS GOARCH GOMAJORVERSION GOMINORVERSION GOPOINTVERSION GOTIPCOMMIT
{
	"GOARCH": "amd64",
	"GOOS": "linux",
	"GOVERSION": "devel go1.20-1eeb257b88 Tue Sep 20 02:58:09 2022 +0000",
        "GOMAJORVERSION": 1, 
        "GOMINORVERSION": 20,
        "GOPOINTVERSION": 0, 
        "GOTIPCOMMIT": "1eeb257b88"
}

@mvdan
Copy link
Member

mvdan commented Sep 30, 2022

For actual releases, it seems to me like you can extract the semver-like numbers with a fairly simple regular expression. I've done that in a couple of places and it doesn't seem particularly difficult.

For "devel" versions, note that they don't need to follow a specific format. A build can end up with any version string placed in the VERSION file when running make.bash. It's true that builds by default end up with a format that includes a commit hash and a timestamp, but - again those feel rather easy to extract via a regular expression or string handling.

Not least of which for passing into go commands such as go mod tidy which has a -compat argument, which requires just the major.minor version number.

Note that if this is your use case, you likely don't want to obey go env GOVERSION if it is not a proper stable release. The current master, even though it's 1.20-somecommit, is very different from what the final Go 1.20 will be like.

It sounds to me like you only want to use GOVERSION when it's a stable version - in which case you only need to trim the bugfix release if there is one.

@willhughes-au
Copy link
Author

willhughes-au commented Oct 4, 2022

I can use a regex, that's what all the search results for "How to get Go version" do. Some of them are broken in various ways, need maintenance, or assume access to certain tooling or a particular regex implementation.

The point of the proposal is to do away with this. It's information that the Go binary already has, why not make it available in a structured way rather than making everyone re-implement the wheel in various broken ways?

@rsc rsc changed the title proposal: cmd/go should output structured version information usable by development tools (and go itself) proposal: cmd/go: add go version -json Dec 4, 2023
@rsc
Copy link
Contributor

rsc commented Dec 4, 2023

When using CI Tools and pipelines, it is often required to know the major/minor version of Go.

I'm not sure I understand when this would happen at all, certainly not "often".

Not least of which for passing into go commands such as go mod tidy which has a -compat argument, which requires just the major.minor version number.

The -compat argument predates the work on forward compatibility (respecting the go version in the go.mod file) and basically should not be used anymore.

Are there other contexts where this information is needed?

@rsc
Copy link
Contributor

rsc commented Dec 4, 2023

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Dec 6, 2023

Talked to @bcmills and @matloob, and we think probably if this information is anywhere it would be in go list -f context.something, but it's unclear why it's necessary so we should establish a use case first.

@rsc
Copy link
Contributor

rsc commented Dec 13, 2023

With the compatibility work that has landed since this issue was filed in 2022, it seems like this may not be necessary anymore.

@rsc
Copy link
Contributor

rsc commented Dec 14, 2023

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Dec 21, 2023

No change in consensus, so declined.
— rsc for the proposal review group

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Declined
Development

No branches or pull requests

5 participants