Hacker News Reader

Comment by uasi | Hacker News Reader

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

View on HN

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.

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.

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.

Reply on news.ycombinator.com