Fabric与dep

接触Golang有2年时间了，从最初学习的时候简单地采用GOPATH开始，作为一个写过几年代码的人就有点奇怪，从 Java 的Maven到Node.js的npm，Golang的这种代码管理方式有点思维的跳跃。但是也勉强接受了，个人开发来说没什么大问题，所有的第三方包都由自己维护，但是采用Git协作的话就有点不知所云了，每个人都要维护统一的第三方包。后来就采用 Govendor 来统一管理维护项目的第三方包。上述是个人使用经验，可能是我入 Golang 这行较晚，很多依赖管理 工具 没赶上潮流吧，自带学 Go 之后，Govendor便是主流工具。

Fabric包管理工具的变更

Govendor也是之前很长一段时间Hyperledger Fabric所采用的依赖管理工具，但是在17年11月22日在Jira上便开始讨论是否采用dep来进行包依赖管理，毕竟在混乱的年代，第三方的包管理工具不是一个长久之计，dep当时已经成为Go的官方包管理工具的一个候选者，在1.2版本中，Fabric开始采用dep作为依赖管理工具。

但是在与此同时出现了vgo,然后随着go v1.11的出现，vgo又更名为go modules，真的是百家争鸣那。现在Fabric主项目采用的是dep，而fabric ca项目不知道是因为进度缓慢还是考虑到go modules会发布，还在采用govendor进行包管理。

在Jira上，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 中，已经明确发现了dep现在的迭代只是因为go modules还不太稳定。想必在19年Fabric会逐渐替换dep以及Fabric CA中的govendor，希望go modules可以终结Golang混乱的包管理机制。

欢迎关注我的公众号:AwesomeBlockchain，获取更多技术文章！