我无法真正理解拥有供应商文件夹的目的。根据我了解到的情况,供应商文件夹似乎只有在您尝试使您的存储库与1.11
. 我们正在运行 golang 1.12.14
。
当我把这件事告诉我的同事时,他说:
请使用带有模块的供应商 - go 没有全局工件。目前,这是确保您拥有密封构建并且当有人在其存储库中更改某些内容时您的代码不会中断的最佳选择。
我以为这就是 Go 模块的作用?我问了这个问题,评论者说我不应该使用供应商?将 `go mod vendor` 添加到预提交挂钩是否有意义?
我无法真正理解拥有供应商文件夹的目的。根据我了解到的情况,供应商文件夹似乎只有在您尝试使您的存储库与1.11
. 我们正在运行 golang 1.12.14
。
当我把这件事告诉我的同事时,他说:
请使用带有模块的供应商 - go 没有全局工件。目前,这是确保您拥有密封构建并且当有人在其存储库中更改某些内容时您的代码不会中断的最佳选择。
我以为这就是 Go 模块的作用?我问了这个问题,评论者说我不应该使用供应商?将 `go mod vendor` 添加到预提交挂钩是否有意义?
Go 模块保证了你将能够通过将依赖项锁定到一个go.sum
. 话虽这么说,确定性构建项目的承诺只有在您的依赖项将来仍然可以访问时才有效。你不知道会不会是这样。
另一方面,无论有没有 Go 模块,供应商都会带来更强的保证,因为它可以在代码旁边提交依赖项。因此,即使不再可以访问远程存储库(删除、重命名等),您仍然可以构建您的项目。
另一种选择是使用 Go 模块和代理。您可以在官方文档中找到更多信息。您还可以查看一些 OSS 实现,例如gomods/athens或goproxy/goproxy。如果您不想设置和维护自己的代理,市场上有一些商业优惠。
那么你应该go mod vendor
每次提交吗?好吧,最终取决于您想要的保证类型。但是,是的,利用代理或出售您的依赖项有助于更接近可重现的构建。
注意:使用 Go 1.17,go mod vendor
(来自1.17 Go commands)可能更容易使用:
供应商内容
如果主模块指定 go 1.17 或更高版本,则
go mod vendor
现在使用每个供应商模块在其自己的文件vendor/modules.txt
中指示的 go 版本进行注释。 从供应商的源代码构建模块包时使用带注释的版本。go.mod
如果主模块指定 go 1.17 或更高版本,
go mod vendor
现在省略go.mod
和go.sum
文件供应商依赖项,否则可能会干扰 go 命令在供应商树中调用时识别正确模块根的能力。