The go dependency management tool for people who don't like go dependency management tools.
Vendetta is a minimal tool for managing the dependencies in the
vendor directory of a go project. Go supports such directories
from version 1.5, but doesn't
provide a way to manage their contents. Vendetta is less obtrusive
than other go dependency management tools because it relies on git
submodules. You don't need vendetta to build a project, or for most
other development tasks. Vendetta is just used to populate the
vendor directory with submodules, or to update them when a project's
dependencies change. Because it uses git submodules, your project
repository remains small, and it is easy to relate the contents of the
vendor directory back to their origin repositories.
If you have your GOPATH set up:
go get github.com/dpw/vendetta
This will install
If you don't:
git clone https://github.com/dpw/vendetta.git && (cd vendetta ; go build)
vendetta binary will be in the cloned
The directory specified should be the top-level directory of the git repo that holds your Go project. If it is omitted, the current directory is used.
go get, vendetta identifies any missing packages needed to
build your top-level project (including packages needed by other
dependencies). It then finds the projects containing those missing
packages, and runs the git commands to add submodules for them.
When you clone a project with submodules, as produced by vendetta, the
submodule directories will initially be empty. Do
git submodule update --init --recursive in order to retrieve the submodule
Vendetta follows all the relevant Go conventions, such as ignoring
-p: Prune unneeded submodules under
-u: Update dependencies of your project. This pulls from the remote repositories for required submodules under
Go 1.5 introduced the Go Vendor
feature. This provides support in the standard go tool set for
vendor directories which contain the source code for dependencies of
a project. Note that in Go 1.5, you must set the
GO15VENDOREXPERIMENT environment variable to enable this feature; but
Go 1.6 enables it by default.
The Go Vendor feature is a significant step forward for dependency
management in go. But out of the box, it does not provide a way to
vendor directory for a project with its dependencies,
or manage those dependencies as the project evolves. Trying to do
this by hand is cumbersome and error prone.
Other go vendoring tools are
But they support two approaches: Either they copy the source code of
vendor/, which bloats the repository of your
project. Or, they write a dependency metadata file under
which says how to get the dependencies. But then anyone who wants to
build the project needs to use a specific tool to retrieve the
dependencies. (And there is no dominant standard for the dependency
metadata files – there are even two different formats for a file
Instead, vendetta relies on the submodule feature of git, which provides a way for one git repository to point to another git repository (and a specific commit within it). And submodules are a standard feature of git, so git will retrieve them for you. You may already have experience with submodules. And tools built on top of git understand submodules (e.g. github knows about submodules, and will display a submodule pointing to another project on github as a link).
When you clone a repository containing submodules, you need to do
git submodule update --init --recursive in order to retrieve the
submodule contents. This step is sometimes surprising to those new to
git submodules. But it can be hidden by incorporating it into build
scripts or makefiles. And
go get will do
git submodule update
after cloning a repo, so it is not necessary to run it explicitly when
fetching go packages in that way.
A downside of git submodules is that, being a git-specific feature, they only allow dependencies that live in (or are mirrored to) git repositories. But given the prevalence of git within the go community, and the ease of mirroring other VCSes to git, this is not much of a limitation.