@seankhliao What do you dislike about this proposal?

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.

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.

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

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.

CC @bcmills @matloob