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