Comparison of Go Vendoring Tools

Vendoring for Go language is best presented in Go 1.5 documentation:

Go 1.5 includes experimental support for using local copies of external dependencies to satisfy imports of those dependencies, often referred to as vendoring. Setting the environment variable GO15VENDOREXPERIMENT=1 enables that experimental support.

When the vendor experiment is enabled, code below a directory named “vendor” is importable only by code in the directory tree rooted at the parent of “vendor”, and only using an import path that omits the prefix up to and including the vendor element.

You can read further in Go 1.5 Vendor Experiment design document.

There is a list of tools supporting this feature in Package Management Tools wiki page. I have tested these in a corporate environment (Github Enterpise, firewalls, proxies etc.) for two projects with internal and external dependencies. Starting with the most popular tool, I have used each tool for “saving dependencies” and “updating dependencies”. I have listed the important points and problems occurred with their related Github issues.

Let’s get started:

godep

2919 stars, 257 forks

• Saving Dependencies: “godep save” uses the source files in GOPATH and copies them to vendor folder.
• Updating Dependencies: “godep restore” updates the source files under GOPATH directly.
• Problems: Could not handle recursive vendored projects as mentioned in this issue: godep/issues/370

glide

770 stars, 39 forks

• Saving Dependencies: “glide init” & “glide install”: Checks the source codes and creates YAML files with locked versions (glide.lock files)
• Updating Dependencies: “glide up” is mentioned as updating dependencies recursively.
• Problems: YAML files (configuration files) could not be constructed properly for my case as mentioned in this issue: glide/issues/163

govendor

174 stars, 16 forks

• Saving Dependencies: “govendor init” checks the source code and creates configuration file.
• Updating Dependencies: “govendor add” & “govendor update” gets source code from GOPATH and copies under vendor or updates.
• Good Points: It shows the scope and status of dependencies such as “external”, “vendor”, “local” etc. and it has commands to manage dependencies with their scopes.

gvt

148 stars, 12 forks

• Saving Dependencies: No command for saving the dependencies is found.
• Updating Dependencies: “gvt fetch” gets the dependencies from external repositories. “gvt update” gets the dependencies from local repositories.
• Problems: It is not working with enterprise Git repositories, therefore not completely tested.
• Good Points: It is well-documented and intuitive to use, I will use if there is no Enterprise Github related issues. It also fetches dependencies from external resources, which is good for updating dependencies.

To conclude, I will be using govendor for corporate projects since it worked as expected without any problems but I will try gvt in my personal projects.

Feel free to add your comments about these or any other additional vendoring tools.