proposal: cmd/go: list versions of `go install`-able package

[endigma]

Proposal Details

When wrapping go install for use in https://github.com/jdx/mise, I've run into the issue of not being able to consistently find a list of installable versions for a go install-able package URL.

Example:

go list -m -versions -json github.com/go-task/task/v3/cmd/task returns:

{
        "Path": "github.com/go-task/task/v3/cmd/task",
        "Origin": {
                "VCS": "git",
                "URL": "https://github.com/go-task/task",
                "Subdir": "v3/cmd/task",
                "TagPrefix": "v3/cmd/task/",
                "TagSum": "t1:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="
        }
}

Any software looking to find a list of valid versions for github.com/go-task/task/v3/cmd/task I believe has to just check:

• github.com/go-task/task/v3/cmd/task
• github.com/go-task/task/v3/cmd
• github.com/go-task/task/v3

before finding the "root" of the module. This is further complicated by the way major versions are incorporated into the path when the module root is not the repository root.

It would be very useful if go install could have a flag to list installable versions (with json?), as it does this check somewhere internally to provide it's current functionality of checking if a version is valid.

[endigma]

@seankhliao What do you dislike about this proposal?

[seankhliao]

I don't think go ever needs to build out the full matrix of installable versions, it only needs to check for a single set of versions: the one given or latest.

[endigma]

I don't want to build them, I want to list them, for a tool which needs to offer the list of installable version tags. go list can already do this, just not reliably for subpackages.

[seankhliao]

i said build out the list, not build the code. Go never needs the list that you want.

Further conflating packages with module versioning does not seem like a good idea, we already see many issues when people have with overlapping module boundaries.

Also, it is entirely possible for a given package path to exist at the "same" version in multiple modules, these do not conflict as long as they're never imported into the same build graoh:

• module: example/a, version v0.1.0, package example/a/b
• module: example/a/b version v0.1.0, package example/a/b

[endigma]

I need the list I want, go also never needs the list from go list -m -versions? These are tools for users, the proposal just extends existing functionality to work with subpackages. The alternative is naively redacting the path until a valid answer comes back.

This would mirror functionality available in other package-install tools:

• cargo install --list
• pnpm show xyz versions
• many more

Since go install is the go equivalent of cargo install or pnpm install -g, I don't see why it shouldn't have a similar option to list the available versions.

As for the confusing path specification, that's further justification for this to be information attainable from the toolchain, that way wrapping tools don't have to make a naive implementation of the same functionality that might not have the same consideration as a cmd/go feature.

I think the point of the proposal is clear, thank you for writing out your criticism instead of just leaving a 👎, even if I don't agree with it.

[ianlancetaylor]

CC @bcmills @matloob