资讯专栏INFORMATION COLUMN

Fabric与dep

王陆宽 / 982人阅读

摘要:但是在与此同时出现了然后随着的出现,又更名为,真的是百家争鸣那。采用文件来追踪依赖,而不是的和文件。然而他们并不想提交大量的文件,因为链码程序仅仅是个小的代码库。想必在年会逐渐替换以及中的,希望可以终结混乱的包管理机制。

作者: TopJohn
原文连接:https://www.xuanzhangjiong.to...
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,获取更多技术文章!

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/24525.html

相关文章

  • 基于Docker & Fabric的Web项目部署方案

    本文描述了Web项目的两种部署方案,石器时代的ssh & pull & restart方式不做太多说明 1.基于Fabric(Python)的部署方案 Fabric 是一个用于ssh的Python库&命令行工具 Fabric is a Python (2.5-2.7) library and command-line tool for streamlining the use of SSH for...

    SKYZACK 评论0 收藏0
  • 基于Docker & Fabric的Web项目部署方案

    本文描述了Web项目的两种部署方案,石器时代的ssh & pull & restart方式不做太多说明 1.基于Fabric(Python)的部署方案 Fabric 是一个用于ssh的Python库&命令行工具 Fabric is a Python (2.5-2.7) library and command-line tool for streamlining the use of SSH for...

    RyanHoo 评论0 收藏0
  • Hyperledger Fabric(目录)

    摘要:企业区块链平台企业级许可的分布式分类账平台,为广泛的行业用例提供模块化和多功能性。这些节点通过应用已经由共识协议验证的交易来维护分类帐的副本,该交易被分组为包括将每个块绑定到前一个块的散列的块中。 企业区块链平台 企业级许可的分布式分类账平台,为广泛的行业用例提供模块化和多功能性。 介绍 一般而言,区块链是一个不可变的交易分类账,维护在一个分布式对等节点网络中。这些节点通过应用已经由共...

    trigkit4 评论0 收藏0
  • Hyperledger Fabric周周记:起源

    摘要:作为系列的新篇章,我选择从超级账本的开始。为什么选择超级账本作为起点我在之前的文章中曾说过会从超级账本入手开始区块链的学习和实践,同时也给出了个人的理由。检查事务提议的响应。为了降低区块链应用的开发难度,超级账本项目又引入了。 本着以教带学,Learning by Doing的想法,我于上周加入了Bob组织的HiBlock区块链技术布道群。这个群可不太好混,群规要求每个成员必需每周有输...

    hatlonely 评论0 收藏0
  • Hyperledger Fabric(关键概念介绍)

    摘要:还提供创建通道的功能,允许一组参与者创建单独的交易分类账。共识交易必须按照发生的顺序写入分类账,即使它们可能位于网络中不同的参与者组之间。 介绍 Hyperledger Fabric是分布式分类账解决方案的平台,采用模块化架构,提供高度机密性,弹性,灵活性和可扩展性,它旨在支持不同组件的可插拔实现,并适应整个经济生态系统中存在的错综复杂的事物和复杂性。 我们建议首次使用的用户首先阅读下...

    joy968 评论0 收藏0

发表评论

0条评论

王陆宽

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<