我应该使用 go mod 提交供应商目录吗？

Question

我在 go1.12 上使用 go 模块来处理我的 Go 依赖项。将目录提交vendor/到版本控制是否是最佳做法？这与提交“供应商”目录是否是最佳实践有关？在使用的情况下会问这个问题dep。使用dep，提交vendor/是获得真正可重复构建的唯一方法。go 模块呢？

Answer 1

除非您需要修改供应商的软件包，否则您不应该这样做。Go 模块已经为您提供了可重复的构建，因为该go.mod文件记录了您的依赖项的确切版本和提交哈希，该go工具将尊重并遵循这些。

该vendor目录可以通过运行go mod vendor命令重新创建，并且默认情况下它甚至会被忽略，go build除非您要求它与-mod=vendor标志一起使用。

Answer 2

我想给出一些支持提交的论据vendor，go.mod和go.sum。

我同意接受的答案的论点，即它在技术上是不必要的并且会使回购膨胀。

但这里有一个反论点列表：

• 构建项目不依赖于 Github/Gitlab/... 或 Go 代理服务器上可用的某些代码。开源项目可能会因为审查、作者激励、许可变更或其他一些我目前无法想到的原因而消失，这确实发生在 JavaScript 包管理器 npm 上，并且破坏了许多项目。不在您的仓库中，不在您的代码中。

• 我们可能使用了内部或第 3 方 Go 模块（私有），它们也可能消失或无法访问，但如果它们在供应商中提交，它们就是我们项目的一部分。没有什么意外中断。

• 私有 Go 模块可能不遵循语义版本控制，这意味着 Go 工具在动态获取它们时将依赖最新的提交哈希。回购历史可能会被重写（例如 rebase），您、同事或您的 CI 工作最终可能会为他们使用的依赖项编写不同的代码。

• 提交供应商可以改善您的代码审查过程。通常，我们总是在单独的提交中提交依赖项更改，因此如果您好奇，可以轻松查看它们。

这是一个与膨胀回购有关的有趣观察。如果我进行代码审查并且团队成员包含了一个包含 300 个文件的新依赖项（或更新了一个包含 300 个文件更改的依赖项），我会非常好奇地深入研究它并开始讨论代码质量，这种更改的必要性或替代 Go 模块。这实际上可能会导致您的二进制文件大小和整体复杂性降低。

如果我在新的合并请求中只看到一个新行，go.mod我什至不会考虑它。

• 执行编译和构建步骤的 CI/CD 作业无需在每次执行 CI 作业时浪费时间和网络来下载依赖项。所有需要的依赖项都是本地的并且存在（go build -mod vendor）

这些都在我头上，如果我记得还有什么，我会在这里添加。