作者: TopJohn https://www.xuanzhangjiong.top/about/
个人感受
接触 Golang 有 2 年时间了, 从最初学习的时候简单地采用 GOPATH 开始, 作为一个写过几年代码的人就有点奇怪, 从 Java 的 Maven 到 Node.JS 的 NPM,Golang 的这种代码管理方式有点思维的跳跃. 但是也勉强接受了, 个人开发来说没什么大问题, 所有的第三方包都由自己维护, 但是采用 Git 协作的话就有点不知所云了, 每个人都要维护统一的第三方包. 后来就采用 Govendor https://github.com/kardianos/govendor 来统一管理维护项目的第三方包. 上述是个人使用经验, 可能是我入 Golang 这行较晚, 很多依赖管理工具没赶上潮流吧, 自带学 Go 之后, Govendor 便是主流工具.
Fabric 包管理工具的变更
Govendor 也是之前很长一段时间 Hyperledger Fabric 所采用的依赖管理工具, 但是在 17 年 11 月 22 日在 Jira https://jira.hyperledger.org/browse/FAB-7083 上便开始讨论是否采用 dep 来进行包依赖管理, 毕竟在混乱的年代, 第三方的包管理工具不是一个长久之计, dep 当时已经成为 Go 的官方包管理工具的一个候选者, 在 1.2 版本中, Fabric 开始采用 dep 作为依赖管理工具.
但是在与此同时出现了 vgo, 然后随着 go v1.11 的出现, vgo 又更名为 go modules, 真的是百家争鸣那. 现在 Fabric 主项目采用的是 dep, 而 fabric ca 项目不知道是因为进度缓慢还是考虑到 go modules 会发布, 还在采用 govendor 进行包管理.
在 Jira https://jira.hyperledger.org/browse/FAB-10562 上, 18 年 6 月 6 日的时候有一个讨论, 说的是 vgo 的提案已经被 go 官方接受了, Fabric 团队需要考虑 vgo 在未来对 Fabric 的影响. 当然下述的文字表述仅仅是对历史的一个回顾, 现在 vgo 这个词也已经不存在了.
Vgo 的 Roadmap:
18 年 7 月 - 计划 Go v1.11 release(包括'vgo'的预览版)
19 年 1 月 - 计划 Go v1.12 release(完全包括'vgo')
Dep vs Vgo
dep 和 vgo 主要的差异在于, dep 是一个单独的依赖管理工具, 而 vgo 则是 go 命令的一个替代品. 当你运行 vgo build 时, 就像运行 go build, 但是 vgo 会自动帮你解决依赖. vgo 采用 go.mod 文件来追踪依赖, 而不是 dep 的 Gopkg.lock 和 Gopkg.toml 文件.
使用 vgo 同样允许链码相关的依赖在安装的时候能够自动下载并导入到二进制中. 这意味着我们可以忽略 vendor 目录就像 node_modules 目录一样.
说说 Chaincode 中的包管理
场景
如果一个用户写了一个带有几个外部依赖的链码程序. 他将采用 dep 去管理依赖和 shim 层. 然而他们并不想提交大量的文件, 因为链码程序仅仅是个小的代码库.
当前的实现
在进行 install 的时候, 为了保证所有的依赖都被包括进链码的容器里, 用户被要求强制提交 vendor 目录, 否则编译将会失败.
建议的实现
当链码构建的时候, 我们会搜索 Gopkg.toml 和 Gopkg.lock 文件. 如果它们存在的话, 我们会运行 dep ensure 命令. 这将会从相关的源头获取相关的依赖, 然后不需要用户提交依赖的前提下将依赖构建进二进制中.
要值得注意的是, 如果用户希望提交 vendor 目录 (比如 peer 节点无法拉取相应的依赖的情况下), 这仍然有效 - 而且还有个好处是使用 dep ensure - 将保证提交的依赖是通过校验的.
总结
个人观点, 自从 Golang v1.11 发布之后 go modules 的出现, Fabric 采用原生 go modules 替代 dep 是迟早的事, 在 GitHub https://github.com/golang/dep 中, 已经明确发现了 dep 现在的迭代只是因为 go modules 还不太稳定. 想必在 19 年 Fabric 会逐渐替换 dep 以及 Fabric CA 中的 govendor, 希望 go modules 可以终结 Golang 混乱的包管理机制.
来源: https://juejin.im/post/5c3dff06f265da61117a87f8