Dep

dep seems to work great for those who are able to get it to work with their projects. But often, there are issues that a new dep user faces while trying out dep for the first time. The issues when dep fails to solve the dependency graph. When this happens, dep needs some help from the user to solve the issue. A lot of people find it hard to get started with dep when the very first command, dep init fails and they don’t know how to go ahead with that.

Along with managing project dependencies, dep also provides a way to manage the development tools (linters, generators, etc) to be used with the project. This can be done by adding the tool’s full package path in the required field in the manifest file (Gopkg.toml). Unlike other fields, required considers packages, not project. Hence, if a project wants to install a tool, say dep, required should contain github.com/golang/dep/cmd/dep. required = ["github.com/golang/dep/cmd/dep"] If a project doesn’t contain any import path of a package, required field can be used to tell dep to include that.

This post is about a feature in golang/dep that could be used by developers who are not using vendor directory to vendor their dependencies, but depend on the version of the dependencies checked out in their GOPATH. dep provides a subcommand, dep init, for initializing a go project to use dep. It creates two files, a manifest file, called Gopkg.toml, and a lock file, called Gopkg.lock. These files contain details about all the dependencies analyzed by dep while initializing.