4 ms·

> Instead, just look at go.mod. It lists the precise version at which all dependencies are built. No, it does not. Minimum version selection means that the lib

> Instead, just look at go.mod. It lists the precise version at which all dependencies are built. No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. That I'm reading this blog post at all suggests there is a "market" for a single checksum/version manifest, which data is currently housed in go.sum . This is sad, but, Hyrum's Law and all that.

deleted 10mo ago
[deleted]
LukeShu 10mo ago
The correct answer is `go mod vendor && cat vendor/modules.txt`
- saghm 10mo ago
  Just to clarify, this will download the entirety of all of the dependencies in order to find out what versions are resolved? And then those versions aren't actually locked unless you keep the vendored dependencies around indefinitely? My understanding is that the point of a lockflle is that you don't need to do that.
- deleted 9mo ago
  [deleted]
ncruces 9mo ago
> No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. No? All dependencies - direct and indirect - are listed in your go.mod. Your module - as is - depends on nothing else. And those exact versions will be used to build it, if yours is the main module. If your module is used as a dependency of another module, then yes, your module may be built with a newer version of those dependencies. But that version will be listed in that module's go.mod. There's no way to use different versions without them being listed in some go.mod. go.sum to only maps between versions and hashes, and may contain hashes for multiple versions of modules.
- skywhopper 9mo ago
  But a “version” as listed in go.mod may have different hashes over time, if tags are changed. That’s the issue.
  - jchw 9mo ago
    This doesn't make any sense to me. If you wanted to verify the contents of a dependency, you would want to check go.sum. That's what it is there for, after all. So if you wanted to fetch the dependencies, then you would want to use it to verify hashes. If all you care about the is the versions of dependencies, you really can (and should) trust go.mod alone. You can do this because there are multiple overlapping mechanisms that all ensure that a tag is immutable once it is used: - The Go CLI tools will of course use the go.sum file to validate that a given published version of a module can never change (at least since it was depended on, but it also is complementary with the features below as well, so it can be even better than that.) - Let's say you rm the go.sum file. That's OK. They also default to using the Go Sum DB to verify that a given published version of a module can never change. So if a module has ever been `go get`'d by a client with the Sum DB enabled and it's publicly accessible, then it should be added to the Sum DB, and future changes to tags will cause it to be rejected. - And even then, the module proxy is used by default too, so as soon as a published version is used by anyone, it will wind up in the proxy as long as its under a suitable license. Which means that even if you go and overwrite a tag, almost nobody will ever actually see this. The downside is obviously all of this centralized infrastructure that is depended on, but I think it winds up being the best tradeoff; none of it is a hard dependency, even for the "dependencies should be immutable" aspect thanks to go.sum files. Instead it mostly helps dependency resolution remain fast and reproducible. Most language ecosystems have a hard dependency on centralized infrastructure, whether it is a centralized package manager service like NPM or a centralized repository on GitHub, whereas the centralized infrastructure with Go is strictly complementary and you can even use alternative instances if you want. But digression aside, because of that, you can trust the version numbers in go.mod.
    - terinjokes 9mo ago
      A local cache of sums are also stored in (iirc) $GOCACHE, so even if you delete go.sum from the project, the local toolchain should still be able to verify module versions previously seen without needing to call out to the Sum DB.
PhilippGille 9mo ago
Minimum version selection happens when the go.mod file is updated, so it contains the minimum versions already. It doesn't happen only later at build time. For example: - `go get x@v1.0.0` => Your go.mod contains `x v1.0.0` - `go get y@v1.0.0` with y having x v1.0.1 as dep => Your go.mod is already updated with the resolved minimum selected version: `x v1.0.1` This requires using Go commands to manage the go.mod file. If you edit it in a text editor then a final `go mod tidy` will help.
uasi 9mo ago
I'm not deeply familiar with this, but from reading the `go mod tidy` manual[1], it seems that running `go mod tidy` loads all packages imported from the main module (including transitive dependencies) and records them with their precise versions back to `go.mod`, which should prevent them from being substituted with later versions. Am I understanding this correctly? [1]: https://go.dev/ref/mod#go-mod-tidy https://go.dev/ref/mod#go-mod-tidy
- kadoban 9mo ago
  go.mod will always match whatever versions are being used directly, as far as I know. But it's not possible to lock them using go.mod. Like if you wanted to bump one version only in go.mod, you're then stumped for actually doing that. Because _probably_ the only reasonable way to get that to build is to do `go mod tidy` after doing that, which will modify go.mod itself. And you can't _really_ go back in and undo it unless you just manually do all of go.mod and go.sum yourself.
  - ncruces 9mo ago
    Running `go mod tidy` months apart with no other changes to your module will not change your go.mod. It certainly won't update dependencies. You run that when you've made manual changes (to go.mod or to your Go code), or when you want to slim down your go.sum to the bare minimum needed for the current go.mod. And that's one common way to update a dependency: you can edit your go.mod manually. But there are also commands to update dependencies one by one.
  - arccy 9mo ago
    go always requires a dependency graph that is consistent with all the declared requirements. Which means if you wanted to update one version, it might bump up the requirements on its dependencies, and that's all the changes you see from running go mod tidy afterwards. Manually constructing an inconsistent dependency graph will not work.
jchw 9mo ago
The MVS choices will be encoded into the go.mod; you may have been correct in the past, but as the post mentions transitive dependencies have been incorporated since Go 1.17. So yes, really: the only point of go.sum is to enable checking the integrity of dependencies, as a nice double-check against the sumdb itself.
arccy 9mo ago
This comment suggests that there is a "market" for confidently incorrect, contrarian HN comments. This is sad, but, Hyrum's Law and all that.
FiloSottile 9mo ago
No. As explained in the post, if a transitive dependency asks for a later version than you have in go.mod, that’s an error if -mod is readonly (the default for non-get non-tidy commands). I encourage you to experiment with it! This is exactly how the “stricter” commands of other package managers work with lockfiles.

deleted 10mo ago

[deleted]

LukeShu 10mo ago

The correct answer is `go mod vendor && cat vendor/modules.txt`

saghm 10mo ago
Just to clarify, this will download the entirety of all of the dependencies in order to find out what versions are resolved? And then those versions aren't actually locked unless you keep the vendored dependencies around indefinitely? My understanding is that the point of a lockflle is that you don't need to do that.
deleted 9mo ago
[deleted]

ncruces 9mo ago

> No, it does not. Minimum version selection means that the libraries will at least be that version, but it could be substituted for a later version if a transient dependency asks for such. No? All dependencies - direct and indirect - are listed in your go.mod. Your module - as is - depends on nothing else. And those exact versions will be used to build it, if yours is the main module. If your module is used as a dependency of another module, then yes, your module may be built with a newer version of those dependencies. But that version will be listed in that module's go.mod. There's no way to use different versions without them being listed in some go.mod. go.sum to only maps between versions and hashes, and may contain hashes for multiple versions of modules.

skywhopper 9mo ago
But a “version” as listed in go.mod may have different hashes over time, if tags are changed. That’s the issue.
- jchw 9mo ago
  This doesn't make any sense to me. If you wanted to verify the contents of a dependency, you would want to check go.sum. That's what it is there for, after all. So if you wanted to fetch the dependencies, then you would want to use it to verify hashes. If all you care about the is the versions of dependencies, you really can (and should) trust go.mod alone. You can do this because there are multiple overlapping mechanisms that all ensure that a tag is immutable once it is used: - The Go CLI tools will of course use the go.sum file to validate that a given published version of a module can never change (at least since it was depended on, but it also is complementary with the features below as well, so it can be even better than that.) - Let's say you rm the go.sum file. That's OK. They also default to using the Go Sum DB to verify that a given published version of a module can never change. So if a module has ever been `go get`'d by a client with the Sum DB enabled and it's publicly accessible, then it should be added to the Sum DB, and future changes to tags will cause it to be rejected. - And even then, the module proxy is used by default too, so as soon as a published version is used by anyone, it will wind up in the proxy as long as its under a suitable license. Which means that even if you go and overwrite a tag, almost nobody will ever actually see this. The downside is obviously all of this centralized infrastructure that is depended on, but I think it winds up being the best tradeoff; none of it is a hard dependency, even for the "dependencies should be immutable" aspect thanks to go.sum files. Instead it mostly helps dependency resolution remain fast and reproducible. Most language ecosystems have a hard dependency on centralized infrastructure, whether it is a centralized package manager service like NPM or a centralized repository on GitHub, whereas the centralized infrastructure with Go is strictly complementary and you can even use alternative instances if you want. But digression aside, because of that, you can trust the version numbers in go.mod.
  - terinjokes 9mo ago
    A local cache of sums are also stored in (iirc) $GOCACHE, so even if you delete go.sum from the project, the local toolchain should still be able to verify module versions previously seen without needing to call out to the Sum DB.

PhilippGille 9mo ago

Minimum version selection happens when the go.mod file is updated, so it contains the minimum versions already. It doesn't happen only later at build time. For example: - `go get x@v1.0.0` => Your go.mod contains `x v1.0.0` - `go get y@v1.0.0` with y having x v1.0.1 as dep => Your go.mod is already updated with the resolved minimum selected version: `x v1.0.1` This requires using Go commands to manage the go.mod file. If you edit it in a text editor then a final `go mod tidy` will help.

uasi 9mo ago

I'm not deeply familiar with this, but from reading the `go mod tidy` manual[1], it seems that running `go mod tidy` loads all packages imported from the main module (including transitive dependencies) and records them with their precise versions back to `go.mod`, which should prevent them from being substituted with later versions. Am I understanding this correctly? [1]: https://go.dev/ref/mod#go-mod-tidy https://go.dev/ref/mod#go-mod-tidy

kadoban 9mo ago
go.mod will always match whatever versions are being used directly, as far as I know. But it's not possible to lock them using go.mod. Like if you wanted to bump one version only in go.mod, you're then stumped for actually doing that. Because _probably_ the only reasonable way to get that to build is to do `go mod tidy` after doing that, which will modify go.mod itself. And you can't _really_ go back in and undo it unless you just manually do all of go.mod and go.sum yourself.
- ncruces 9mo ago
  Running `go mod tidy` months apart with no other changes to your module will not change your go.mod. It certainly won't update dependencies. You run that when you've made manual changes (to go.mod or to your Go code), or when you want to slim down your go.sum to the bare minimum needed for the current go.mod. And that's one common way to update a dependency: you can edit your go.mod manually. But there are also commands to update dependencies one by one.
- arccy 9mo ago
  go always requires a dependency graph that is consistent with all the declared requirements. Which means if you wanted to update one version, it might bump up the requirements on its dependencies, and that's all the changes you see from running go mod tidy afterwards. Manually constructing an inconsistent dependency graph will not work.

jchw 9mo ago

The MVS choices will be encoded into the go.mod; you may have been correct in the past, but as the post mentions transitive dependencies have been incorporated since Go 1.17. So yes, really: the only point of go.sum is to enable checking the integrity of dependencies, as a nice double-check against the sumdb itself.

arccy 9mo ago

This comment suggests that there is a "market" for confidently incorrect, contrarian HN comments. This is sad, but, Hyrum's Law and all that.

FiloSottile 9mo ago

No. As explained in the post, if a transitive dependency asks for a later version than you have in go.mod, that’s an error if -mod is readonly (the default for non-get non-tidy commands). I encourage you to experiment with it! This is exactly how the “stricter” commands of other package managers work with lockfiles.