logoalt Hacker News

djha-skinlast Thursday at 6:06 AM8 repliesview on HN

> 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.


Replies

ncruceslast Thursday at 7:25 AM

> 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.

show 1 reply
FiloSottilelast Thursday at 11:42 AM

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.

PhilippGillelast Thursday at 7:28 AM

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 [email protected]` => Your go.mod contains `x v1.0.0`

- `go get [email protected]` 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.

uasilast Thursday at 7:39 AM

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

show 1 reply
jchwlast Thursday at 10:42 AM

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.

arccylast Thursday at 11:04 AM

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

LukeShulast Thursday at 6:48 AM

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

show 2 replies