在 Go 中处理依赖项

Question

在 Go 中，如果您引用另一个包，例如 GitHub 上的某个包，那么 Go 总是从master分支获取最新版本。虽然这对开发非常有用，但我想这是生产中的一个问题：这样构建是不可重现的。那么，Go 中修复依赖版本的正确方法是什么，以及如何有效地处理它？一位朋友向我指出了Godep，这看起来不错，但我想知道有哪些替代方案，以及 Godep 的优点/缺点是什么？

Answer 1

使用 Go 1.11 更新 2018

现在应该使用模块引用依赖项（源自vgo 项目）：

Go 1.11 添加了对称为“模块”的新概念的初步支持，这是GOPATH对版本控制和包分发的集成支持的替代方案。
使用模块，开发人员不再局限于在内部工作GOPATH，版本依赖信息是明确而轻量的，并且构建更加可靠和可重现。

请参阅定义模块。（和原始设计方案）

---

2015 年 6 月更新：Go 1.5 中首次支持 vendoring！
见c/10923/：

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

• 如果存在源目录d/vendor，则在以 为根的子树中编译源文件时d，将import "p"被解释为就import "d/vendor/p"好像它存在一样。

• 当有多种可能的解决方案时，最具体（最长）的路径获胜。

• 必须始终使用缩写形式：任何导入路径都不能/vendor/明确包含“ ”。

• 在供应商包中忽略导入注释。

---

2015 年 3 月更新：go 团队正在考虑定义一个集成到该语言的 go 依赖管理系统：争论就在这个线程中。

我们认为是时候开始解决依赖和供应问题了，尤其是在 Go 生态系统中出现太多冲突工具和碎片化最佳实践，不必要地使工具复杂化之前。如果社区能够以标准的方式与供应商汇合，那就太好了。

我们的建议是 Go 项目，

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

2. 为依赖项和供应商定义了一个通用的配置文件格式

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

---

Godep 的一个可能的缺点是您不能再直接使用“go build”或“go test”。
您需要在这些命令之前使用godep(或键入godep save)。

另一种选择是glide，它仍然与经典的 go 命令兼容。

• 管理特定于项目的 GOPATH

• 简化依赖管理

• 支持版本控制包

• 支持别名包（例如用于使用 github 分支）

• 消除对“供应商”或修改导入语句的需要

• 使用所有 go 工具

---

更一般地说，“了解您的保证，Go 版本”一文很有趣：

这也是一个深思熟虑的选择，当 Go 的作者认为权衡不利时，他们选择不实现某个功能。

他们做出这种选择的一个低级原因是避免编译缓慢和二进制文件膨胀（这是同一枚硬币的两个方面）。
请记住，包依赖于其他包。所以Foo可能取决于Bar2.1。Foo也可能取决于Baz哪个又取决于Bar1.9，然后在树下。所以这意味着编译和链接几乎相同代码的几个副本。

依赖同一个包的多个版本也意味着知道哪个版本正在调用，从而依赖混乱会渗透到你的源代码中。

这将我们引向了 Go 平台在此功能上下注背后的高级推理：他们没有一个他们认为可以接受的逻辑解决方案。不是他们不了解问题；只是，目前，没有他们喜欢的解决方案。所以他们不选择任何特征而不是回归特征。