go - 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 will try to look for a branch based on your Go version and default to master if I understand correctly.

So there is no way to import a specific release of a dependency, e.g.:

import "github.com/RichardKnop/somelibrary#v1.4.8"

What is the best practise to manage dependencies in Go then?

I can see two approaches.

I. Version Modules

Is it to create new modules for major versions with breaking changes?

For example, my Go library could define modules v1 and v2 so then you could do:

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

Or:

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

Based on what you need. Any changes made to v1 or v2 would be required not to break any APIs or working functionality.

II. Forking

This would give you a complete control over a version of external dependency your Go code requires.

For example, you could fork github.com/RichardKnop/somelibrary into your own GitHub account and then in your code do:

import "github.com/ForkingUser/somelibrary"

Then you would have to fork all external dependencies which seems a bit overkill. However it would give you total control over versions. You could keep your forks at a version you know is working with your code and only update forks once you have checked that new releases of dependencies do not break anything.

Thoughts?

question from:https://stackoverflow.com/questions/30300279/golang-dependency-management-best-practice

Answer 1

Note: June 2015, the first support for vendoring appears in Go 1.5!

See c/10923/:

When GO15VENDOREXPERIMENT=1 is in the environment, this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:

• If there is a source directory d/vendor, then, when compiling a source file within the subtree rooted at d, import "p" is interpreted as import "d/vendor/p" if that exists.
• When there are multiple possible resolutions, the most specific (longest) path wins.
• The short form must always be used: no import path can contain “/vendor/” explicitly.
• Import comments are ignored in vendored packages.

---

Update January 2016: Go 1.6 will make vendoring the default.
And as detailed in the article "MOST GO TOOLS NOW WORK WITH GO15VENDOREXPERIMENT":

1.6 brings support for /vendor/ to most tools (like the oracle) out of the box; use the Beta to rebuild them.

• issue 12278 has been resolved.
• there still is an issue with goimports, and there is a CL that can be cherry-picked.