-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: go list -e -m -json all
to start displaying hashes of modules
#52792
Comments
cc: @bcmills |
With this change gazelle can invoke `update-repos` by processing `go.work` files. The basis of the change is a plain copy-paste of `update.go` into `work.go`. However, since `go list` does not show module sums, the whole process is delegated to `go mod download`. golang/go#52792 was created to track the above. The standard go tooling in 1.18 can work with `go.work` files so not many changes were actually necessary. A smoke test is also added to `update_import_test.go` to verify that the latest version of govmomi and rest is always picked. How to invoke: $ gazelle update-repos -from_file=go.work -to_macro=deps.bzl%go_deps -prune=True
With this change gazelle can invoke `update-repos` by processing `go.work` files. The basis of the change is a plain copy-paste of `update.go` into `work.go`. However, since `go list` does not show module sums, the whole process is delegated to `go mod download`. golang/go#52792 was created to track the above. The standard go tooling in 1.18 can work with `go.work` files so not many changes were actually necessary. A smoke test is also added to `update_import_test.go` to verify that the latest version of govmomi and rest is always picked. How to invoke: $ gazelle update-repos -from_file=go.work -to_macro=deps.bzl%go_deps -prune=True
With this change gazelle can invoke `update-repos` by processing `go.work` files. The basis of the change is a plain copy-paste of `update.go` into `work.go`. However, since `go list` does not show module sums, the whole process is delegated to `go mod download`. golang/go#52792 was created to track the above. The standard go tooling in 1.18 can work with `go.work` files so not many changes were actually necessary. A smoke test is also added to `update_import_test.go` to verify that the latest version of govmomi and rest is always picked. How to invoke: $ gazelle update-repos -from_file=go.work -to_macro=deps.bzl%go_deps -prune=True
GoModSum would at least need to be a []string. When we do a transition to a new algorithm there will be multiple checksums. |
This proposal has been added to the active column of the proposals project |
Looks like we dropped the ball on go mod download -json about string vs []string. Let's keep GoModSum a single string, and maybe in the future we'll have to add GoModSums listing all of them. |
SGTM. For reference. the |
So this would be two new fields for the type Module struct {
Path string // module path
Version string // module version
Versions []string // available module versions (with -versions)
Replace *Module // replaced by this module
Time *time.Time // time version was created
Update *Module // available update, if any (with -u)
Main bool // is this the main module?
Indirect bool // is this module only an indirect dependency of main module?
Dir string // directory holding files for this module, if any
GoMod string // path to go.mod file used when loading this module, if any
GoVersion string // go version used in module
Retracted string // retraction information, if any (with -retracted or -u)
Error *ModuleError // error loading module
Sum string // checksum for path, version (as in go.sum)
GoModSum string // checksum for go.mod (as in go.sum)
} (Note that this would leave at least a couple of fields present in |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
go list -e -m -json all
to start displaying hashes of modulesgo list -e -m -json all
to start displaying hashes of modules
With this change gazelle can invoke `update-repos` by processing `go.work` files. The basis of the change is a plain copy-paste of `update.go` into `work.go`. However, since `go list` does not show module sums, the whole process is delegated to `go mod download`. golang/go#52792 was created to track the above. The standard go tooling in 1.18 can work with `go.work` files so not many changes were actually necessary. A smoke test is also added to `update_import_test.go` to verify that the latest version of govmomi and rest is always picked. How to invoke: $ gazelle update-repos -from_file=go.work -to_macro=deps.bzl%go_deps -prune=True
Change https://go.dev/cl/539575 mentions this issue: |
Change https://go.dev/cl/562775 mentions this issue: |
Fixes golang#52792 Tested: Ran go test cmd/go Change-Id: Ib7006256f4dca9e9fbfce266c00253c69595d6ab Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/562775 Reviewed-by: Bryan Mills <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Proposal source: Gophers Slack
I came to notice that the
go
tool does not list module hash sums when thelist -e -m -json all
command is invoked.That is not the case with
go mod download -json
The proposal here is to extend the underlying data structures of
go list -m
to present information such asSum
andGoModSum
, just likego mod download -json
. By definition, "The -m flag causes list to list modules instead of packages.", therefore I believe it makes sense for the module data to include hash information.Also, it would be useful if
go list -m
can also function in workspace mode, meaning that it would present the hashes of the modules after MVS has been applied to all of them, but that is conditional logic onGOWORK
.The target struct to modify might be this:
go/src/cmd/go/internal/modinfo/info.go
Lines 12 to 27 in 53f1312
... and its implementation of the Stringer interface:
go/src/cmd/go/internal/modinfo/info.go
Lines 33 to 65 in 53f1312
The text was updated successfully, but these errors were encountered: