Gol*_*den 7 go dependency-management
在Go中,如果你引用另一个包,例如GitHub上的东西,那么Go总是从master分支中获取最新版本.虽然这对于开发很有用,但我认为这是生产中的一个问题:这样一种构建是不可重现的.
那么,Go中修复依赖项版本的正确方法是什么,以及如何有效地处理这种情况？
一位朋友给我指了godep,这看起来很好,但我想知道有什么替代方案,以及godep有什么好/坏？
使用Go 1.11更新2018
现在应该使用模块引用依赖项(从vgo项目派生):
Go 1.11增加了对称为"模块"的新概念的初步支持,这是
GOPATH对版本控制和软件包分发的集成支持的替代方案.
使用模块,开发人员不再局限于在内部工作GOPATH,版本依赖性信息是显式的,而且是轻量级的,并且构建更可靠和可重复.
2015年6月更新:第一次支持vendoring正在进入Go 1.5!
见c/10923 /:
当
GO15VENDOREXPERIMENT=1在环境中,这种CL变化的根据围棋1.5供应商建议的进口路径的分辨率:
- 如果存在源目录
d/vendor,则在根据子树的子树中编译源文件时d,import "p"将其解释为import "d/vendor/p"存在.- 当存在多种可能的分辨率时,最具体(最长)的路径获胜.
- 必须始终使用简短形式:没有导入路径可以
/vendor/显式包含" ".- 在vendored包中忽略导入注释.
2015年3月更新:go团队正在考虑定义与该语言集成的go依赖管理系统:辩论就在这个主题中.
我们认为现在是时候开始解决依赖性和销售问题了,特别是在出现太多冲突工具并在Go生态系统中破坏最佳实践之前,不必要地使工具复杂化.如果社区能够以标准的方式融入供应商,那将是一件好事.
我们的建议是Go项目,
- 官方建议使用导入重写(而不是修改)作为引入依赖关系的规范方法来销售到" 内部 "目录
GOPATH.- 为依赖项和vendoring定义了一个通用的配置文件格式
cmd/go在Go 1.5中没有对代码进行任何更改.诸如"godep"或"nut"的外部工具将实现1)和2).我们可以在Go 1.6+中重新评估包括这样的工具.
godep的一个可能的缺点是你不能再直接使用"go build"或"go test"了.
您需要在这些命令之前加上godep(或键入godep save).
另一种选择是滑动,它与经典的go命令兼容.
- 管理项目特定的GOPATH
- 轻松依赖管理
- 支持版本控制包
- 支持别名包(例如,用于使用github forks)
- 无需"vendoring"或修改import语句
- 使用所有go工具
更一般地说,文章" 了解你的保证,Go版 "很有意思:
这也是一个深思熟虑的选择,当Go作者认为权衡不利时,他们选择不实施某项功能.
他们做出这种选择的一个低级别原因是避免编译速度慢和臃肿的二进制文件(这是同一枚硬币的两面).
请记住,包依赖于其他包.所以Foo可能取决于Bar2.1.Foo也可能还取决于Baz哪个依赖于Bar1.9,而依赖于树.这意味着要编译和链接几个相同代码的副本.根据同一个软件包的多个版本,还意味着知道哪个版本正在调用,从而依赖性混乱渗透到您的源代码中.
这导致我们对Go平台支持这一特性的高层次推理:他们没有一个他们认为可以接受的逻辑解决方案.并不是他们不理解这个问题; 就是这样,目前还没有他们喜欢的解决方案.因此,他们选择的功能不会超过回归功能.