Golang 依赖管理最佳实践

Question

在Golang中，我们可以指定GitHub上的开源库作为依赖。例如:

import "github.com/RichardKnop/somelibrary"

这将尝试根据您的 Go 版本寻找分支，如果我理解正确的话，默认为 master。

因此无法导入特定版本的依赖项，例如:

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

那么在 Go 中管理依赖项的最佳实践是什么？

我可以看到两种方法。

我。版本模块

是否为具有重大更改的主要版本创建新模块？

例如，我的 Go 库可以定义模块 v1 和 v2，这样您就可以:

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

或者:

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

根据您的需要。对 v1 或 v2 所做的任何更改都需要不破坏任何 API 或工作功能。

二。 fork

这会让您完全控制您的 Go 代码所需的外部依赖版本。

例如，您可以将 github.com/RichardKnop/somelibrary fork 到您自己的 GitHub 帐户中，然后在您的代码中执行:

import "github.com/ForkingUser/somelibrary"

然后你将不得不 fork 所有看起来有点过分的外部依赖项。但是，它会让您完全控制版本。您可以将您的 fork 保持在您知道正在使用您的代码的版本，并且只有在您检查新版本的依赖项不会破坏任何内容后才更新 fork 。

想法？

Answer 1

二月。 2018 年:如果将 vgo 集成到工具链中，下面介绍的 vendor 方法(2015/2016 年)可能最终会消失。
参见 my answer below .

---

2015 年 8 月版:Go 1.5 带有内置(但仍处于试验阶段) vendor 支持。设置环境变量 GO15VENDOREXPERIMENT 将使 go build 和 friend 在 ./vendor 目录和 GOPATH 中寻找包>。参见 VonC's answer和 design document了解更多详情。

---

三。供应

据我所知，这是确保您的构建可重现和可预测的最广泛使用的方法。 Go 团队本身 uses vendoring在他们的 repo 协议(protocol)中。 Go 团队现在正在讨论统一的依赖 list 文件格式。来自Go toolchain developers mailing list :

In Google’s internal source tree, we vendor (copy) all our dependencies into our source tree and have at most one copy of any given external library. We have the equivalent of only one GOPATH and rewrite our imports to refer to our vendored copy. For example, Go code inside Google wanting to use “golang.org/x/crypto/openpgp” would instead import it as something like “google/third_party/golang.org/x/crypto/openpgp”.

(...)

Our proposal is that the Go project,

• officially recommends vendoring into an “internal” directory with import rewriting (not GOPATH modifications) as the canonical way to pin dependencies.

• defines a common config file format for dependencies & vendoring

• makes no code changes to cmd/go in Go 1.5. External tools such as “godep” or “nut” will implement 1) and 2). We can reevaluate including such a tool in Go 1.6+.