我在 go1.12 上使用 go 模塊來處理我的 Go 依賴項。將目錄也提交到版本控制中是否是最佳實踐vendor/？這與提交 `vendor` 目錄是否是最佳實踐有關？在使用的情況下會問這個問題dep。使用dep，提交vendor/是獲得真正可重復構建的唯一方法。那么 go 模塊呢？
2 回答
胡說叔叔
TA貢獻1804條經驗 獲得超8個贊
我想給出一些支持提交vendor、go.mod和的論據go.sum。
我同意已接受答案的論點，即它在技術上是不必要的并且會使回購協議膨脹。
但這里有一個相反的論點列表：
構建項目并不依賴于 Github/Gitlab/... 或 Go 代理服務器上可用的某些代碼。開源項目可能會因為審查、作者激勵、許可變更或其他一些我目前無法想到的原因而消失，這種情況確實發生在 JavaScript 包管理器 npm 上，并破壞了許多項目。不在您的存儲庫中，不在您的代碼中。
我們可能使用了內部或第 3 方 Go 模塊（私有），這些模塊也可能會消失或變得無法訪問，但如果它們在供應商中提交，那么它們就是我們項目的一部分。沒有任何事情會意外發生。
私有 Go 模塊可能不遵循語義版本控制，這意味著 Go 工具在動態獲取它們時將依賴最新的提交哈希。回購歷史記錄可能會被重寫（例如變基），并且您、同事或您的 CI 工作可能最終會為他們使用的依賴項得到不同的代碼。
承諾供應商可以改進您的代碼審查流程。通常，我們總是在單獨的提交中提交依賴項更改，因此如果您好奇的話可以輕松查看它們。
這是一個與存儲庫膨脹相關的有趣觀察。如果我進行代碼審查，并且團隊成員包含了一個包含 300 個文件的新依賴項（或更新了一個包含 300 個文件更改的依賴項），我會非常好奇地深入研究該依賴項并開始討論代碼質量以及此更改的必要性或替代的 Go 模塊。這實際上可能會減少二進制文件的大小和整體復雜性。
如果我只在新的合并請求中看到一個新行go.mod，我很可能不會考慮它。
執行編譯和構建步驟的 CI/CD 作業不需要在每次執行 CI 作業時浪費時間和網絡來下載依賴項。所有需要的依賴項都是本地的并且存在 (?
go build -mod vendor)
這些都是我的想法，如果我還記得什么，我會在這里補充。
大話西游666
TA貢獻1817條經驗 獲得超14個贊
除非您需要修改供應的軟件包，否則您不應該這樣做。Go 模塊已經為您提供了可重復的構建，因為go.mod文件記錄了依賴項的確切版本和提交哈希值，該go工具將尊重并遵循這些哈希值。
可以通過運行該命令vendor來重新創建該目錄go mod vendor，并且默認情況下它甚至會被忽略，go build除非您要求它與標志一起使用-mod=vendor。
- 2 回答
- 0 關注
- 117 瀏覽
添加回答
舉報
0/150
提交
取消