在 Go 中，如果您引用另一個包，例如 GitHub 上的某個包，那么 Go 總是從master分支獲取最新版本。雖然這對開發非常有用，但我想這是生產中的一個問題：這樣構建是不可重現的。那么，Go 中修復依賴版本的正確方法是什么，以及如何有效地處理它？一位朋友向我指出了Godep，這看起來不錯，但我想知道有哪些替代方案，以及 Godep 的優點/缺點是什么？
2 回答
郎朗坤
TA貢獻1921條經驗 獲得超9個贊
使用 Go 1.11 更新 2018
現在應該使用模塊引用依賴項（源自vgo 項目）：
Go 1.11 添加了對稱為“模塊”的新概念的初步支持，這是
GOPATH對版本控制和包分發的集成支持的替代方案。
使用模塊，開發人員不再局限于在內部工作GOPATH，版本依賴信息是明確而輕量的，并且構建更加可靠和可重現。
請參閱定義模塊。（和原始設計方案）
2015 年 6 月更新：Go 1.5 中首次支持 vendoring！
見c/10923/：
當
GO15VENDOREXPERIMENT=1在環境中時，此 CL 根據 Go 1.5 供應商建議更改導入路徑的解析：
如果存在源目錄
d/vendor，則在以 為根的子樹中編譯源文件時d，將import "p"被解釋為就import "d/vendor/p"好像它存在一樣。當有多種可能的解決方案時，最具體（最長）的路徑獲勝。
必須始終使用縮寫形式：任何導入路徑都不能
/vendor/明確包含“ ”。在供應商包中忽略導入注釋。
2015 年 3 月更新：go 團隊正在考慮定義一個集成到該語言的 go 依賴管理系統：爭論就在這個線程中。
我們認為是時候開始解決依賴和供應問題了，尤其是在 Go 生態系統中出現太多沖突工具和碎片化最佳實踐，不必要地使工具復雜化之前。如果社區能夠以標準的方式與供應商匯合，那就太好了。
我們的建議是 Go 項目，
官方建議通過導入重寫（而不是修改）作為固定依賴項的規范方式供應到“內部”目錄
GOPATH。為依賴項和供應商定義了一個通用的配置文件格式
cmd/go在 Go 1.5 中不做任何代碼更改。外部工具如“godep”或“nut”將實現1）和2）。我們可以重新評估在 Go 1.6+ 中包含這樣的工具。
Godep 的一個可能的缺點是您不能再直接使用“go build”或“go test”。
您需要在這些命令之前使用godep(或鍵入godep save)。
另一種選擇是glide，它仍然與經典的 go 命令兼容。
管理特定于項目的 GOPATH
簡化依賴管理
支持版本控制包
支持別名包（例如用于使用 github 分支）
消除對“供應商”或修改導入語句的需要
使用所有 go 工具
更一般地說，“了解您的保證，Go 版本”一文很有趣：
這也是一個深思熟慮的選擇，當 Go 的作者認為權衡不利時，他們選擇不實現某個功能。
他們做出這種選擇的一個低級原因是避免編譯緩慢和二進制文件膨脹（這是同一枚硬幣的兩個方面）。
請記住，包依賴于其他包。所以Foo可能取決于Bar2.1。Foo也可能取決于Baz哪個又取決于Bar1.9，然后在樹下。所以這意味著編譯和鏈接幾乎相同代碼的幾個副本。依賴同一個包的多個版本也意味著知道哪個版本正在調用，從而依賴混亂會滲透到你的源代碼中。
這將我們引向了 Go 平臺在此功能上下注背后的高級推理：他們沒有一個他們認為可以接受的邏輯解決方案。不是他們不了解問題；只是，目前，沒有他們喜歡的解決方案。所以他們不選擇任何特征而不是回歸特征。
- 2 回答
- 0 關注
- 271 瀏覽
添加回答
舉報
0/150
提交
取消