go icon indicating copy to clipboard operation
go copied to clipboard

proposal: cmd/go: a command to obtain data about other module versions which are available

Open mitar opened this issue 1 year ago • 1 comments
trafficstars

Proposal Details

This is a followup to https://github.com/golang/go/issues/40323. In there the proposal was to print out warnings during other commands when there are newer versions of modules available.

This proposal instead proposes a new sub-command to go mod, something like go mod check or go mod upgradeable which would check existing dependencies for:

  • Deprecations.
  • Available minor versions.
  • Available major versions.

It could print that out in readable format or in JSON format (so that other tools could take that as input). I think this would allow then various plumbing with CI and other tooling to get warnings, errors, notifications, e-mail notifications, whatever. It would also not pollute all other go commands with messages people might not expect. I can imagine then somebody making a linter for golangci-lint which would require that everything is on the latest version. Or whichever policy you want.

The command could then also be extended in the future (suggesting fixes, adding additional checks - like suggesting which version changes might reduce the number of different versions in the program) without adding noise to existing other commands.

mitar avatar May 16 '24 07:05 mitar

Proposal Details

This is a followup to #40323. In there the proposal was to print out warnings during other commands when there are newer versions of modules available.

This proposal instead proposes a new sub-command to go mod, something like go mod check or go mod upgradeable which would check existing dependencies for:

  • Deprecations.
  • Available minor versions.
  • Available major versions.

It could print that out in readable format or in JSON format (so that other tools could take that as input). I think this would allow then various plumbing with CI and other tooling to get warnings, errors, notifications, e-mail notifications, whatever. It would also not pollute all other go commands with messages people might not expect. I can imagine then somebody making a linter for golangci-lint which would require that everything is on the latest version. Or whichever policy you want.

The command could then also be extended in the future (suggesting fixes, adding additional checks - like suggesting which version changes might reduce the number of different versions in the program) without adding noise to existing other commands.

That would be useful instead of currently having to manually click Check for upgrades | Upgrade transitive dependencies | Upgrade direct dependencies in the IDE.

H0llyW00dzZ avatar May 16 '24 08:05 H0llyW00dzZ

CC @matloob

ianlancetaylor avatar May 20 '24 04:05 ianlancetaylor

Maybe that command could provide more info than just versions, to avoid having to introduce multiple such go mod subcommands over time. Consider for example composer show <package> --all providing all metadata about a package.

Otherwise, we have prior art like composer outdated, yarn outdated, npm outdated. And there is a similar discussion in the Rust community at https://github.com/rust-lang/cargo/issues/4309#issuecomment-317505200 (open since 2017), which includes a nice summary of equivalent features in other languages as prior art.

fgm avatar May 20 '24 11:05 fgm

cc @samthanawalla

This seems like it could be useful.

matloob avatar May 20 '24 16:05 matloob

@seankhliao You changed the title, but my proposal is for both major and minor versions.

mitar avatar May 20 '24 18:05 mitar

I did, but minor version info is already available (the -u and -versions flag for go list). What's new and hard is obtaining information about major versions.

seankhliao avatar May 20 '24 18:05 seankhliao

Hm, I was hoping for one command to show me all version information. But yes, adding major is new and hard, but I still think it is useful to have one command which can show both. One reason is that you can sometimes then see that a module has both a newer minor and newer major version, implying that the old major version is still maintained.

mitar avatar May 20 '24 19:05 mitar

Having a single clear place to go to get all version related questions answered is good UX. I don't want to have to remember two things. That's one too many things!

jimmyfrasche avatar May 20 '24 19:05 jimmyfrasche

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 avatar May 23 '24 18:05 rsc

What if we add a new MajorUpdate field to the Module struct that is output from go list -m, with these semantics:

  • go list -m -u # sets Deprecated, Update (latest minor) (this already exists)
  • go list -m -u=patch # sets Deprecated, Update (latest patch; this would be new)
  • go list -m -u=major # sets Deprecated, Update (latest minor), MajorUpdate (this adds MajorUpdate)

Would that be enough for people?

rsc avatar Jun 05 '24 17:06 rsc

Have all remaining concerns about this proposal been addressed?

The proposal details are in https://github.com/golang/go/issues/67420#issuecomment-2150584249.

rsc avatar Jun 12 '24 20:06 rsc

I think so. Thanks.

mitar avatar Jun 12 '24 20:06 mitar

Yes, they do.

gaby avatar Jun 12 '24 22:06 gaby

Would -u=major also contain the results for -u=patch and just -u; or would it only show major updates?

jimmyfrasche avatar Jun 12 '24 22:06 jimmyfrasche

No, each -u contains one result, since the (pre-existing) Update field can only describe one version.

rsc avatar Jun 20 '24 18:06 rsc

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

The proposal details are in https://github.com/golang/go/issues/67420#issuecomment-2150584249.

rsc avatar Jun 24 '24 18:06 rsc

No change in consensus, so accepted. 🎉 This issue now tracks the work of implementing the proposal. — rsc for the proposal review group

The proposal details are in https://github.com/golang/go/issues/67420#issuecomment-2150584249.

rsc avatar Jun 27 '24 13:06 rsc

Does this proposal include a corresponding change to the module proxy? Perhaps a prefix filter for index.golang.org?

GET https://index.golang.org/index?prefix=github%2Ecom%2Ffoo%2Fbar

icholy avatar Oct 27 '24 12:10 icholy