3 ms·

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wan

by mxey 4mo ago

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

awesome_dude 4mo ago
I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.
- deleted 4mo ago
  [deleted]
- 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 ago
      Indeed, 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 ago
        Yes, 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.
- mxey 4mo ago
  Pinning to me means there is a file with all the versions as they will be used. I don’t see how “go mod tidy” modifying it is different from “bundle install” modifying it.
  - awesome_dude 4mo ago
    [dead]

by mxey 4mo ago

awesome_dude 4mo ago

I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.

deleted 4mo ago
[deleted]
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 ago
    Indeed, 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 ago
      Yes, 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.
mxey 4mo ago
Pinning to me means there is a file with all the versions as they will be used. I don’t see how “go mod tidy” modifying it is different from “bundle install” modifying it.
- awesome_dude 4mo ago
  [dead]