Golang Dependency Management Best Practice

Question

In Golang, we can specify open source libraries on GitHub as dependencies. For example:

import \"github.com/RichardKnop/somelibrary\"

This

Answer 1

Update August 2018: this (vgo presented below) is now implemented with Go 1.11 and modules.

Update Feb. 2018, 3 years later.

There is a new approach developed by Russ Cox, from the core Golang development team.

The vgo project.

go get -u golang.org/x/vgo

This proposal:

• keeps the best parts of go get,
• adds reproducible builds,
• adopts semantic versioning,
• eliminates vendoring,
• deprecates GOPATH in favor of a project-based workflow, and
• provides a smooth migration path from dep and its predecessors.

It is based on a new MVS ("Minimal Version Selection") algorithm:

You can see:

• the first articles in Go & Versioning
• the discussion in this thread
• the analysis of that thread by Jon Calhoun
• the counter-point by Sam Boyer in "Thoughts on vgo and dep":
  He was leading the private initiative of go dep
• the first debate (YouTube) between Russ, Sam and Jesse Frazelle!

---

May 2018: Artifactory proposes a vgo proxy

The recent release of Artifactory 5.11 added support for vgo-compatible Go registries (and go proxy) giving the community a variety of capabilities when developing with Go.
Here are just a few of them:

• Local repositories in Artifactory let you set up secure, private Go registries with fine-grained access control to packages according to projects or development teams.
• A remote repository in Artifactory is a caching proxy for remote Go resources such as a GitHub project. Accessing a go proxy through Artifactory removes your dependency on the network, or on GitHub since all dependencies needed for your Go builds are cached in Artifactory and are therefore locally available. This also removes the risk of someone mutating or removing a dependency from version control, or worse, force-pushing changes to a remote Git tag thus changing what should be an immutable version which can create a lot of confusion and instability for dependent projects.
• A virtual repository aggregates both local and remote Go registries giving you access to all Go resources needed for your builds from a single URL, hiding the complexity of using a combination of both local and remote resources.