登录
首页 >  Golang >  Go问答

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

来源:stackoverflow

时间:2024-04-13 19:12:31 280浏览 收藏

IT行业相对于一般传统行业,发展更新速度更快,一旦停止了学习,很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习,精进自己的技术,尤其是初学者。今天golang学习网给大家整理了《我应该使用 go mod 提交供应商目录吗?》,聊聊,我们一起来看看吧!

问题内容

我在 go1.12 上使用 go 模块来处理我的 Go 依赖项。将 vendor/ 目录也提交到版本控制中是否是最佳实践?

这与提交 `vendor` 目录是否是最佳实践有关?在使用 dep 的情况下会问这个问题。使用 dep,提交 vendor/ 是获得真正可重现构建的唯一方法。那么 go 模块呢?


解决方案


我想提供一些支持提交 vendorgo.modgo.sum 的论点。

我同意已接受答案的论点,即它在技术上是不必要的并且会使存储库膨胀。

但这里有一个支持论点的列表:

  • 构建项目并不依赖于 Github/Gitlab/... 或 Go 代理服务器上可用的某些代码。开源项目可能会因为审查、作者激励、许可变更或我目前无法想到的其他一些原因而消失,其中 did happen on npm, the JavaScript package manager, and broke many projects不在您的存储库中,不在您的代码中。

  • 我们可能使用了内部或第 3 方 Go 模块(私有),这些模块也可能会消失或变得无法访问,但如果它们是在供应商中提交的,那么它们就是我们项目的一部分。 没有什么会意外发生。

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

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

  • 不需要设置 CI/CD 作业身份验证来下载私有 Go 模块(更简单)。

  • Go 依赖项几乎总是文本文件(源代码),并且将它们存储在存储库中非常便宜。其他所有语言的情况并非如此。

  • 承诺供应商有时可能会改进代码审查流程。通常,我们总是在单独的提交中提交依赖项更改,因此如果您好奇的话可以轻松查看它们。

这是一个与存储库膨胀相关的有趣观察。如果有人进行代码审查,并且团队成员包含了一个包含 300 个文件的新依赖项(或更新了一个包含 300 个文件更改的依赖项),那么深入了解并最终开始讨论替代方案/质量(如果需要)可能会很有趣。这实际上可能会减少二进制文件的大小和整体复杂性。

如果新合并请求中的 go.mod 中只有一个新行,我们很可能不会考虑它。

何时提交供应商是错误的?

当项目是 Go 库时,

vendor 永远不应该提交(想象一下您制作了新的 gorilla/mux)。仅适用于生成可执行二进制文件的项目。

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

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

阅读更多详细信息:

Go wiki: How do I use vendoring with modules? Is vendoring going away?

Command go: Modules and vendoring

Command go: Make vendored copies of dependencies

理论要掌握,实操不能落!以上关于《我应该使用 go mod 提交供应商目录吗?》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>