一張圖看懂Go包管理歷史

時間 2019-11-08

標籤一張看懂包管歷史简体版

原文原文鏈接

來源：cyningsun.github.io/09-07-2019/…html

時間線

2012年3月 Go 1 發佈，此時沒有版本的概念
2013年 Golang 團隊在 FAQ 中提議開發者保證相同 import path 的兼容性，後來成爲一紙空文
2013年10月 Godep
2014年7月 glide
2014年有人提出 external packages 的概念，在項目的目錄下增長一個 vendor 目錄來存放外部的包
2015年8月 Go 1.5 實驗性質加入 vendor 機制
2015年有人提出了採用語義化版本的草案
2016年2月 Go 1.6 vendor 機制默認開啓
2016年5月 Go 團隊的 Peter Bourgon 創建委員會，討論依賴管理工具，也就是後面的 dep
2016年8月 Go 1.7: vendor 目錄永遠啓用
2017年1月 Go 團隊發佈 Dep，做爲準官方試驗
2018年8月 Go 1.11發佈 Modules 做爲官方試驗
2019年2月 Go 1.12發佈 Modules 默認爲 auto

混沌初開

Go 從 Google 走出來，內部使用 blaze 系統，因此項目的源代碼公用一個 repo, 任何修改都要跑 test 保證整個 repo 不出問題。所以 go get僅僅支持獲取 master branch 上的 latest 代碼，沒有指定 version、branch 或 revision 的能力。git

對應的開源的方案就是一個 $GOPATH 走天下，並無關心依賴問題。如此作法會給gopher帶來不便：依賴的第三方包老是在變。一旦第三方包提交了沒法正常build或接口不兼容的代碼，依賴方當即就會受到影響，但開源社區是無窮多個小 repo 的合集，像 go get 直接拉個最新的 master 版本帶來了隱患：依賴一更新，已有代碼就可能編譯不過。github

「If you’re using an externally supplied package and worry that it might change in unexpected ways, the simplest solution is to copy it to your local repository. (This is the approach Google takes internally.) Store the copy under a new import path that identifies it as a local copy. For example, you might copy original.com/pkg to you.com/external/original.com/pkg.」 - Go FAQgolang

八龍治水

第一個主要的社區工具是 Godep。早期它提供了一種方法來快照您在您使用的VCS修訂版GOPATH，而後將其恢復到GOPATH。這爲不一樣的應用程序提供了一種使用相同依賴項的不一樣修訂版的方法。緩存

Godep 確實有一些在應用程序之間切換時必須執行的手動步驟。例如，您須要將該應用程序的依賴項修訂版還原到GOPATH。可是，它能夠與Google工做流程一塊兒工做，所以它能夠工做。app

大約在同一時間，社區自發造成了其餘各式各樣的包管理工具，僅官方推薦的包管理工具總數就有15種之多，大部分工具都解決了差很少的問題，只是使用上有些許的區別。這些眼花繚亂工具，對選擇困難症來講，不是什麼好事情。ide

乾坤始奠

時間走到了 2015 年，Golang 官方終於看不下去了，在推出 go1.5 版本的同時，首次實驗性質的加入了 vendor 機制功能。vendor 標準化了項目依賴的第三方庫的存放位置（再也不須要Godeps/_workspace了），同時也無需對GOPATH環境變量進行「偷樑換柱」了，go compiler原生優先感知和使用vendor下緩存的第三方包。工具

只是有了 vendor，就有了官方的正名！項目的形態也跟之前的統一塊兒來了，好處顯而易見。但即使有了vendor的支持，vendor內第三方依賴包的代碼的管理依舊是不規範的，要麼是手動的，要麼是藉助godep這樣的第三方包管理工具。 Go 項目自身對 vendor 中代碼的管理方式也是手動更新，Go自身並未使用任何第三方的包管理工具。post

從Go官方角度出發，官方go包依賴的解決方案的下一步就應該是解決對vendor下的第三方包如何進行管理的問題：依賴包的分析、記錄和獲取等，進而實現項目的reproducible build。ui

繼往開來

2018年初，Go team 的技術 Leader，Russ Cox 在博客上連續發表七篇文章，系統闡述了 Go team 「包依賴管理」方案: vgo。vgo 主要思路包括：Semantic Import Versioning、Minimal Version Selection、引入Go module等。文章引起了Go社區激烈地爭論，讓不少 Go 包管理工具的維護者「不滿」，其中包括「準官方工具」：dep。vgo方案的提出也意味着dep項目等一系列包管理工具的生命週期即將進入尾聲。

2018年5月，Russ Cox的 Proposal 「cmd/go: add package version support to Go toolchain」被 accepted，此後 vgo 代碼 merge 到 Go 主幹，並正式命名爲「modules」。後續Go modules機制將直接在Go主幹上繼續演化。

參考

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。