如何調(diào)試 Go mod 的各種異常
Go mod 自從誕生之日就帶來了太多太多的爭議，當(dāng)然不能否認(rèn)它的設(shè)計(jì)初衷是好的。然而在調(diào)試其各種異常時(shí)，卻浪費(fèi)了太多開發(fā)者的時(shí)間?？梢院敛豢蜌獾恼f，從來沒有一種語言的版本管理，能讓人如此崩潰。
本文記錄了一些我的踩坑經(jīng)驗(yàn)，希望能給還在掙扎中的 Gopher 一些幫助。
go get
先來看看最近我遇到的一個(gè)問題：
$ go mod tidygo: foo.bar.com/foo/[email protected]: git remote add origin -- https://foo.bar.com/foo/bar.git in /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2: exit status 128:fatal: remote origin already exists.
光從字面上來看，像是一個(gè) git 的問題。一頓?go mod why?和?go mod graph?操作后，也沒有得到什么有價(jià)值的信息。
以我的個(gè)人摸索經(jīng)驗(yàn)來看，
why?和?graph?的輸出就是一坨垃圾，只會(huì)給開發(fā)者帶來更多的心智負(fù)擔(dān)。
實(shí)際上，調(diào)試 go mod 問題最好的工具是?go get?，這樣可以只會(huì)輸出異常模塊的依賴樹，去掉那些煩人的干擾信息。如果再加上?-x?選項(xiàng)后，更是屢試不爽。繼續(xù)拿我遇到的這個(gè)問題開刀：
$ go get-x foo.bar.com/foo/bar# get https://foo.bar.com/foo/bar?go-get=1# get https://foo.bar.com/foo/bar?go-get=1: 200 OK (0.508s)mkdir -p /root/goforge/pkg/mod/cache/vcs # git3 https://foo.bar.com/foo/bar.git# lock /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2.lockmkdir -p /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2 # git3 https://foo.bar.com/foo/bar.gitcd /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2; git init --bare0.011s# cd /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2; git init --barecd /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2; git remote add origin -- https://foo.bar.com/foo/bar.git0.006s# cd /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2; git remote add origin -- https://foo.bar.com/foo/bar.gitgo: foo.bar.com/foo/[email protected]: git remote add origin -- https://foo.bar.com/foo/bar.git in /root/goforge/pkg/mod/cache/vcs/e8ae9003fdd7f44246f94c535282e58436b3568a39734a76af8fac7b716a59b2: exit status 128:fatal: remote origin already exists.
瞧，go get -x?會(huì)幫你把每個(gè)步驟的操作都打出來。顯然這個(gè)問題確實(shí)由 git 引起。大概是?go get?拉取模塊時(shí)，會(huì)先創(chuàng)建一個(gè)裸倉庫，然后?add origin?。問題就發(fā)生在?add origin?這步，git 認(rèn)為已經(jīng)有一個(gè)?origin?存在了。這是為啥呢？不妨去手動(dòng)復(fù)現(xiàn)下：
$ mkdir git_test$ cd git_test$ git init$ git remote add origin -- https://foo.bar.com/foo/bar.gitfatal: remote origin already exists.
繼續(xù)看看，現(xiàn)在這個(gè)倉庫的?origin?是啥：
$ git remote -vorigin
看到這里，突然想起我的 git 配置了?origin?默認(rèn)指向?HEAD：
$ git config -l | grep originbranch.master.remote=originremote.origin.push=HEAD
git 2.20 以上已經(jīng)在一個(gè)空的 origin 上繼續(xù) add 了
刪除了這個(gè)選項(xiàng)后：git config --global --unset remote.origin.push， 終于可以拉取成功了。
replace
試想這么一種場景，假設(shè)有個(gè)項(xiàng)目?foo?依賴 a 的?v1.0.0?版本，而?foo?依賴的 b 依賴了 a 的?v2.0.0?版本。那么這個(gè)時(shí)候?foo?的 mod 其實(shí)最終會(huì)依賴 a 的?v2.0.0?版本。如果你需要?foo?強(qiáng)行依賴?v1.0.0?版本，這個(gè)時(shí)候就派上了 replace 的上場。直接修改 go.mod 文件，添加：replace a => a v1.0.0?即可。
但是實(shí)際情況，往往會(huì)更復(fù)雜。比如 b 需要 a v2.0.0?的一些新特性的話，簡單的?replace?往往不能解決這個(gè)問題。如何解決呢？自己去處理。比如，Kuma[1]?自己維護(hù)了一個(gè)?vendored?文件夾?replace?到本地來處理這種問題；Kubernetes[2]?也有個(gè)自己的?staging。
mod cache
需要注意的是 go 1.12 版本之前，mod cache 并不是并發(fā)安全的，同一個(gè)環(huán)境并發(fā)構(gòu)建可能會(huì)產(chǎn)生競態(tài)。而最新的 go 1.15 還提供了環(huán)境變量?GOMODCACHE?來指定 mod cache 的位置，CI 工具可以利用這項(xiàng)加快構(gòu)建速度。
引用鏈接
[1]?Kuma:?https://github.com/kumahq/kuma/blob/master/vendored/README.md[2]?Kubernetes:?https://github.com/kubernetes/kubernetes/blob/master/staging/README.md
推薦閱讀