Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go.sum is not a lockfile

words.filippo.io

Post reply on HN
Print view View original

11–20 of 81 posts

Re: Go.sum is not a lockfile

#11

Post by ncruces »

djha-skin wrote: post #6

> 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 ho…

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

Re: Go.sum is not a lockfile

#12

Post by PhilippGille »

djha-skin wrote: post #6

> 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 ho…

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.

Re: Go.sum is not a lockfile

#13

Post by Groxx »

saghm wrote: post #10
Groxx wrote: post #5

Earlier quoted context omitted.

The private repo mention in the comments there is kinda a good one, unfortunately. If someone runs a private gosum/goproxy (relatively common) and amends a tag (hopefully very uncommon but I have personally seen it happen at least three times) then the cache could be wrong because go.mod didn't have to change. Which is Bad™ but it depends on what edge cases they want to handle automatically, vs optimization for the m…

From a relatively naive outside perspective, it sounds like this would be pretty much only ever a self-inflicted probably (where "self" might be an org rather than an individual). What you're describing sounds almost like a force push to a private repo; if you're doing that, you might break things for anyone using it, so the risks should probably rest with you for asking so. "This breaks my setup if I modify history…

It's basically a force-push, yeah. Which does happen, like with git, so you do kinda need a way to deal with it even if it's not automatic.

Which it sounds like they have (planned), which seems like a good improvement.

Re: Go.sum is not a lockfile

#14

Post by uasi »

djha-skin wrote: post #6

> 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 ho…

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

Re: Go.sum is not a lockfile

#15

Post by kadoban »

uasi wrote: post #14
djha-skin wrote: post #6

> 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 ho…

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

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.

Re: Go.sum is not a lockfile

#16

Post by ncruces »

kadoban wrote: post #15
uasi wrote: post #14

Earlier quoted context omitted.

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

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 u…

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.

Re: Go.sum is not a lockfile

#17

Post by nasretdinov »

Groxx wrote: post #4

> If the main module imports example.com/mod1/pkg1 and a separate example.com/mod1/pkg2 imports example.com/mod2, there is no way for example.com/mod2 to affect the build or run code on the developer’s machine, so you don’t need to consider it a dependency. iirc (I do not have a test setup at the moment to verify) it does affect your dependency resolution, and therefore your build, though its code does not exist in y…

These libraries are honestly so bad that whenever I have to interact with them I just split those dependencies into a separate binary :)

Re: Go.sum is not a lockfile

#18

Post by wereHamster »

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references.

If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code.

I'm not a go developer and must be misunderstanding something...

Re: Go.sum is not a lockfile

#19

Post by PunchyHamster »

wereHamster wrote: post #18

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references. If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code. I'm not a go developer and must be misunderstanding something...

> I'm not a go developer and must be misunderstanding something...

I think it's coz not EVERY language's lockfile comes with checksum

So, Go's go.mod is functionally equivalent Ruby Gem lockfile (that doesn't have checksum) but need to get go.sum to be equivalent to npm's (that does come with checksum)

Author just compared it to languages where lockfile means just version lock

Re: Go.sum is not a lockfile

#20

Post by wereHamster »

PunchyHamster wrote: post #19
wereHamster wrote: post #18

A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references. If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code. I'm not a go developer and must be misunderstanding something...

> I'm not a go developer and must be misunderstanding something... I think it's coz not EVERY language's lockfile comes with checksum So, Go's go.mod is functionally equivalent Ruby Gem lockfile (that doesn't have checksum) but need to get go.sum to be equivalent to npm's (that does come with checksum) Author just compared it to languages where lockfile means just version lock

Now I understand :) thanks for clarifying
Post reply on HN