TL;DR:

• Side effects are surprising and hard to control.
• Different commands perform different actions on go.mod, which are hard to reason about.
• Official Golang.org and Google projects aren't using semantic versioning, creating uncertainty about whether that's the direction of the ecosystem.
• Future of vendoring is ambiguous.
• Modules pull in more transitive dependencies than per-package vendoring.

On Let's Encrypt's Boulder project we decided it's time to move to Go modules. We've been using godep to vendor our dependencies for a long time but it's no longer maintained. We vendor our dependencies to ensure that we can always deploy, even if an upstream dependency becomes unavailable.

I wanted to separate the task of switching to modules from upgrading any dependencies. I wanted to be easily able to separate any bugs based on changing dependencies from any bugs based on switching to modules.

I started with Boulder at de15c267 go mod init:

In a project already using an existing dependency management tool like godep, glide, or dep, 'go mod init' will also add require statements matching the existing configuration.

This created a go.mod with versions matching what I had in Godeps.json. So far so good. I committed it.

Next I ran go mod verify to check that

https://github.com/thepudds/go-module-knobs/blob/master/README.md https://github.com/golang/go/wiki/Modules#can-i-control-when-gomod-gets-updated-and-when-the-go-tools-use-the-network-to-satisfy-dependencies https://golang.org/cmd/go/#hdr-Thegomodfile https://github.com/golang/go/issues/27005 https://github.com/golang/go/issues/31372 https://godoc.org/cmd/go#hdr-Verifydependencieshaveexpectedcontent https://golang.org/cmd/go/#hdr-Maintainingmodule_requirements https://github.com/golang/go/issues/27227#issuecomment-420428896 https://github.com/golang/go/wiki/ExperienceReports#modules https://research.swtch.com/vgo-mvs