0

I'm "all in" on Go Modules. Mostly, I prefer the experience. In Go development, I've -- perhaps like many others -- treated dependencies as if I worked in a mono repo, each of my projects had its own GOPATH and I'd often clone from scratch and pull all then-latest versions of dependencies.

Using Modules, I think I'm breaking the best practice:

  • For per-commit builds, my projects' go.mod file would contain only primary -- and often only one -- explicit dependencies. Effectively, I don't commit go.mod and leave my build process to generate it and then the build. My thinking being that, apart from e.g. specific platforms that I'm using, where my familiarity with them means I'm confident in pinning to a specific version, for other dependencies, I'd rather maintain currency and get @vLatest.
  • If I get to building releases, I'd then go mod tidy and commit the go.mod to source control for the basis of the build.

Besides:

  • potentially breaking builds (which is acceptable for currency);
  • the absence of go.sum and package hashes (which I'm not independently verifying but trusting, e.g. golang.proxy.org); and
  • the repetition of pulling dependencies which is unavoidable anyway with my build process,

Is this approach bad?

DazWilkin
  • 32,823
  • 5
  • 47
  • 88

1 Answers1

0

For building releases, dependency immutability and build reproducibility are critical to software releases. Relying on go mod tidy to create the go.mod assumes the module git tag is immutable and is always available which is not the case. To ensure that the module tag is persistent and immutable, a go module repository is recommended. Refer to Go1.11 documentation for a list of "always on" module repositories and enterprise proxies. A short video on "Go Module and Dependency Management - GoCenter and Project Athens" talks about immutable dependency management..

Stanley Fong
  • 1