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 或工作功能。

二。分叉

这将使您可以完全控制 Go 代码所需的外部依赖版本。

例如，您可以将 github.com/RichardKnop/somelibrary 分叉到您自己的 GitHub 帐户中，然后在您的代码中执行以下操作：

import "github.com/ForkingUser/somelibrary"

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

想法？

Answer 1

二月。 2018 年：如果将 vgo 集成到工具链中，下面介绍的供应商方法（2015/2016 年）可能最终会消失。
见my answer below。

---

2015 年 8 月版：Go 1.5 带有内置（但仍处于试验阶段）的供应商支持。设置环境变量GO15VENDOREXPERIMENT 将使go build 和朋友在./vendor 目录以及GOPATH 中查找包。请参阅VonC's answer 和design document 了解更多详情。

---

三。贩卖

AFAIK，这是确保构建可重现和可预测的最广泛使用的方法。 Go 团队本身 uses vendoring 在他们的仓库中。 Go 团队现在正在讨论统一的依赖清单文件格式。来自Go toolchain developers mailing list：

在 Google 的内部源代码树中，我们将所有依赖项供应（复制）到我们的源代码树中，并且最多拥有任何给定外部库的一个副本。我们只有一个 GOPATH 并重写我们的导入以引用我们的供应商副本。例如，Google 内部想要使用“golang.org/x/crypto/openpgp”的 Go 代码会将其导入为“google/third_party/golang.org/x/crypto/openpgp”之类的内容。

(...)

我们的建议是 Go 项目，

• 官方建议将通过导入重写（而不是 GOPATH 修改）作为固定依赖项的规范方式将供应商放到“内部”目录中。

• 为依赖项和供应商定义通用配置文件格式

• 在 Go 1.5 中不对 cmd/go 进行任何代码更改。 “godep”或“nut”等外部工具将实现 1) 和 2)。我们可以重新评估在 Go 1.6+ 中包含这样的工具。

Answer 2

注意：2015 年 6 月，Go 1.5 中首次出现了对 vendoring 的支持！

见c/10923/:

当GO15VENDOREXPERIMENT=1在环境中时，此CL根据Go 1.5供应商提议更改导入路径的分辨率：

• 如果存在源目录d/vendor，则在以d 为根的子树内编译源文件时，import "p" 被解释为import "d/vendor/p"（如果存在）。
• 当有多个可能的解决方案时，最具体（最长）的路径获胜。
• 必须始终使用短格式：任何导入路径都不能明确包含“/vendor/”。
• 供应商的软件包中会忽略导入 cmets。

---

2016 年 1 月更新：Go 1.6 将使供应商成为默认设置。
并在the article "MOST GO TOOLS NOW WORK WITH GO15VENDOREXPERIMENT"中详细说明：

1.6 为大多数开箱即用的工具（如 oracle）带来了对/vendor/ 的支持；使用 Beta 版重建它们。

• issue 12278 已解决。
• 还有一个issue with goimports，还有一个CL那个can be cherry-picked。

Answer 3

2018 年 8 月更新：此（如下所示的 vgo）现已通过 Go 1.11 and modules 实施。

2018 年 2 月更新，3 年后。

核心 Golang 开发团队 Russ Cox 开发了一种新方法。

vgo 项目。

go get -u golang.org/x/vgo

这个提议：

• 保留go get的精华部分，
• 添加可重现的构建，
• 采用语义版本控制，
• 消除了供应商，
• 弃用 GOPATH 以支持基于项目的工作流程，并且
• 提供从dep 及其前身的平滑迁移路径。

它基于一个新的MVS ("Minimal Version Selection") algorithm：

你可以看到：

• Go & Versioning的第一篇文章
• discussion in this thread
• analysis of that thread by Jon Calhoun
• Sam Boyer 在“Thoughts on vgo and dep”中的反驳：
  他正在领导 go dep 的私人倡议
• Russ、Sam 和 Jesse Frazelle 之间的 first debate (YouTube)！

---

2018 年 5 月：Artifactory proposes a vgo proxy

最近发布的 Artifactory 5.11 增加了对与 vgo 兼容的 Go 注册表（和 Go 代理）的支持，从而在使用 Go 进行开发时为社区提供了多种功能。
这里只是其中的几个：

• Artifactory 中的本地存储库可让您设置安全的私有 Go 注册表，并根据项目或开发团队对包进行细粒度的访问控制。
• Artifactory 中的远程存储库是远程 Go 资源（例如 GitHub 项目）的缓存代理。通过 Artifactory 访问 go 代理可以消除您对网络或 GitHub 的依赖，因为 Go 构建所需的所有依赖项都缓存在 Artifactory 中，因此在本地可用。这也消除了有人从版本控制中改变或删除依赖项的风险，或者更糟糕的是，强制将更改推送到远程 Git 标签，从而改变了应该是不可变的版本，这会给依赖项目带来很多混乱和不稳定。
• 虚拟存储库聚合了本地和远程 Go 注册表，让您可以从单个 URL 访问构建所需的所有 Go 资源，从而隐藏使用本地和远程资源组合的复杂性。

Answer 4

也可以只在maven中描述依赖关系，如果使用mvn-golang-wrapper，在这种情况下它看起来像在maven中如下文本

<plugin>
 <groupId>com.igormaznitsa</groupId>
 <artifactId>mvn-golang-wrapper</artifactId>
 <version>1.1.0</version>
 <executions>
  <execution>
    <id>golang-get</id>
     <goals>
       <goal>get</goal>
     </goals>
     <configuration>
       <packages>
         <package>github.com/gizak/termui</package>
       </packages>
       <buildFlags>
         <flag>-u</flag>
       </buildFlags>
       <goVersion>1.6</goVersion>
     </configuration>
   </execution>
</plugin>