Handle dependencies in Go

Question

In Go, if you reference another package, e.g. something on GitHub, then Go always gets the latest version from the master branch. While this is great for development, I guess it's a problem in production: This way a build is not reproducible.

So, what is the correct way in Go to fix a version of a dependency, and how to handle this efficiently?

A friend pointed me to godep, and this seems fine, but I wanted to know what alternatives are there, and what's good / bad about godep?

Answer 1

Update 2018 with Go 1.11

Dependencies should now be referenced with modules (derived from the vgo project):

Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution.
Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible.

See Defining a module. (and the original design proposal)

---

Update June 2015: first support for vendoring is making its way in Go 1.5!
See c/10923/:

When GO15VENDOREXPERIMENT=1 is in the environment, this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:

• If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.
• When there are multiple possible resolutions, the most specific (longest) path wins.
• The short form must always be used: no import path can contain “/vendor/” explicitly.
• Import comments are ignored in vendored packages.

---

Update March 2015: the go team is thinking about defining a go dependency management system integrated to the language: the debate is in this thread.

We think it’s time to start addressing the dependency & vendoring issue, especially before too many conflicting tools arise and fragment best practices in the Go ecosystem, unnecessarily complicating tooling. It would be nice if the community could converge on a standard way to vendor.

Our proposal is that the Go project,

1. officially recommends vendoring into an “internal” directory with import rewriting (not GOPATH modifications) as the canonical way to pin dependencies.
2. defines a common config file format for dependencies & vendoring
3. makes no code changes to cmd/go in Go 1.5. External tools such as “godep” or “nut” will implement 1) and 2). We can reevaluate including such a tool in Go 1.6+.

---

One possible downside of godep is that you can no longer use "go build" or "go test" directly.
You need to precede those commands with godep (or type godep save).

An alternative is glide, which remains compatible with classic go commands.

• Manage project-specific GOPATHs
• Ease dependency management
• Support versioning packages
• Support aliasing packages (e.g. for working with github forks)
• Remove the need for "vendoring" or munging import statements
• Work with all of the go tools

---

More generally, the article "Know your guarantees, Go edition" is interesting:

It’s also a deliberate choice, where the Go authors chose not to implement a feature when they felt that the trade-offs were no good.

One low-level reason they made this choice is to avoid slow compilation and bloated binaries (which are two sides of the same coin).
Remember, packages depend on other packages. So Foo might depend on Bar 2.1. Foo might also depend on Baz which in turn depends on Bar 1.9, and on down the tree. So that would mean compiling and linking several copies of nearly identical code.

Depending on several versions of the same package also means knowing which version one is calling, whereby the dependency mess seeps into your source code.

Which leads us to the high-level reasoning behind the Go platform punting on this feature: they did not have a logical solution they considered acceptable. It’s not that they don’t understand the problem; it’s that, at the moment, there is not a solution they like. So they choose no feature over over a regressive one.