Fabric与dep

原文地址：www.xuanzhangjiong.top/2019/01/15/…

做者：TopJohn

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，获取更多技术文章！