3 ms·
There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g.
by kbolino 4mo ago
There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422 https://stackoverflow.com/a/77412524/814422
It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already being used by the build process. In other words, if you see `go mod tidy` change a version, it means that you haven't tidied the file since making other changes to it, and the listing in go.mod was stale with respect to the resolved set of transitive dependencies actually being used.
- mxey 4mo ago> It only syncs go.mod with what is already being used by the build process If dependencies are incomplete, Go will fail to compile and tell you to run go mod tidy to fix it.
- kbolino 4mo agoIndeed, I ran two tests (missing indirect dependency, stale indirect dependency version) and it refused to compile both. Either what I said was never true, or it was only true for earlier versions of the `go` command. Nevertheless, adjusted accordingly, I believe the following statement is true: `go mod tidy` doesn't change versions in go.mod unless it needs to, to satisfy the other dependencies listed in go.mod, or to fill in a missing dependency for an import in code. It would be nice if there were a flag to turn off the latter behavior, though.
- mxey 4mo agoYes, initially modules used to modify the file automatically which is why I have -mod=readonly in some old pipelines. I think the “new” way is much better. I still run tidy in pipelines to check but that’s only for cleanup.