Dependency Management in Go 1.6 is No Longer Painful

⚠️NOTICE: This article was written several years ago and is likely out of date.

Traditionally, Go has handled dependencies by installing them all in the same directory under $GOPATH/src. This works fine if you’re working on a small application you do not care too much about; but if the project is large or has lots of developers, version locking dependencies becomes a must, lest library version mismatches will ruin your day.

The Problem

Version locking dependencies is typically not a problem for the more popular languages; however since Go keeps all dependencies in one area, you could not have more than one version of the same dependency installed. How the community got around this limitation was to abuse go subpackages to store dependencies using tools like Godep. The problem with this approach is that you end up with ridiculously long import paths that are a pain to manage and make vim scream.

import (
	"html/template"
	"net/http"

	// Try checking at a glance at what this really is.
	"github.com/amdrel/really-long-app-name/Godeps/_workspace/src/github.com/gorilla/mux"
	"github.com/amdrel/really-long-app-name/Godeps/_workspace/src/github.com/gorilla/sessions"
)

The Solution

With the release of Go 1.5, an experimental environment variable called GO15VENDOREXPERIMENT was added to solve this problem. The only problem is that it’s not enabled by default so you have to make it clear to contributors it’s required. With the upcoming release of Go 1.6 vendoring is now enabled by default and considered stable.

Vendoring allows Go projects to put dependencies in directory called vendor, and these dependencies can be referenced using the traditional method.

import (
	"html/template"
	"net/http"

	// These will reference the versions under vendor if they exist and fall
	// back to $GOPATH/src if not available.
	"github.com/gorilla/mux"
	"github.com/gorilla/sessions"
)

go get will not manage vendor directories though and leaves that job to tools like Glide. Glide will set up lock files and keep track of project dependencies using a project specific configuration file. These tools are not required and it is up to developers to decide how they want to manage their dependencies.

All in all, dependency management in Go is much less of a pain with vendoring considered stable in the upcoming release of Go 1.6. At the time of this writing, Go 1.6 has yet to release and a release candidate version can be found here. Go 1.6 is now released and can be downloaded here.