在 Go 中处理依赖项答案

【问题标题】：Handle dependencies in Go在 Go 中处理依赖项
【发布时间】：2014-11-28 08:22:10
【问题描述】：

在 Go 中，如果您引用另一个包，例如GitHub 上的东西，然后 Go 总是从 master 分支获取最新版本。虽然这对开发很有好处，但我想这是生产中的一个问题：这样构建是不可重现的。

那么，在 Go 中修复依赖版本的正确方法是什么，以及如何有效地处理呢？

一位朋友指给我godep，这看起来不错，但我想知道有哪些替代品，godep 的优点/缺点是什么？

【问题讨论】：

标签： go dependency-management

【解决方案1】：

使用 Go 1.11 更新 2018 年

Dependencies should now be referenced with modules（源自the vgo project）：

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

请参阅 Defining a module。（和original design proposal）

2015 年 6 月更新：Go 1.5 首次支持供应商！
见c/10923/：

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

如果存在源目录d/vendor，则在以d 为根的子树中编译源文件时，import "p" 将被解释为import "d/vendor/p"（如果存在）。

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

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

供应商的软件包中会忽略导入 cmets。

2015 年 3 月更新：go 团队正在考虑定义一个集成到语言中的 go 依赖管理系统：争论是 in this thread。

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

我们的建议是 Go 项目，

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

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

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

godep 的一个可能缺点是您不能再直接使用“go build”或“go test”。
您需要在这些命令前加上godep（或输入godep save）。

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

管理项目特定的 GOPATH

简化依赖管理

支持版本控制包

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

不再需要“供应商”或修改导入语句

使用所有 go 工具

更一般地说，文章“Know your guarantees, Go edition”很有趣：

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

他们做出这种选择的一个低级原因是为了避免编译缓慢和二进制文件臃肿（这是同一枚硬币的两个方面）。
请记住，软件包依赖于其他软件包。所以Foo 可能依赖于Bar 2.1。 Foo 也可能依赖于 Baz，而 Baz 又依赖于 Bar 1.9，并且依赖于树。所以这意味着编译和链接几份几乎相同的代码。

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

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

【讨论】：

【解决方案2】：

您处理依赖项就像处理其他语言的依赖项一样：您是供应商。对于 Go 来说，没有 Nexus 可以进行供应，所以大多数只是将外部库复制到“供应商”文件夹中，这里有一些工具可以提供帮助。就我个人而言，我发现所有这些“修复版本”的恐慌有点夸张，因为没有它也能很好地工作。

您可能想看看 http://labix.org/gopkg.in 并搜索 golang-nuts 以进行依赖管理。我认为甚至有一个完整的邮件列表专门用于此。

【讨论】：