如何調(diào)試 Go mod 的各種異常

Go mod 自從誕生之日就帶來(lái)了太多太多的爭(zhēng)議，當(dāng)然不能否認(rèn)它的設(shè)計(jì)初衷是好的。然而在調(diào)試其各種異常時(shí)，卻浪費(fèi)了太多開(kāi)發(fā)者的時(shí)間?？梢院敛豢蜌獾恼f(shuō)，從來(lái)沒(méi)有一種語(yǔ)言的版本管理，能讓人如此崩潰。

本文記錄了一些我的踩坑經(jīng)驗(yàn)，希望能給還在掙扎中的 Gopher 一些幫助。

go get

先來(lái)看看最近我遇到的一個(gè)問(wèn)題：

$ 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.

光從字面上來(lái)看，像是一個(gè) git 的問(wèn)題。一頓?go mod why?和?go mod graph?操作后，也沒(méi)有得到什么有價(jià)值的信息。

以我的個(gè)人摸索經(jīng)驗(yàn)來(lái)看，why?和?graph?的輸出就是一坨垃圾，只會(huì)給開(kāi)發(fā)者帶來(lái)更多的心智負(fù)擔(dān)。

實(shí)際上，調(diào)試 go mod 問(wèn)題最好的工具是?go get?，這樣可以只會(huì)輸出異常模塊的依賴樹(shù)，去掉那些煩人的干擾信息。如果再加上?-x?選項(xiàng)后，更是屢試不爽。繼續(xù)拿我遇到的這個(gè)問(wèn)題開(kāi)刀：

$ 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è)步驟的操作都打出來(lái)。顯然這個(gè)問(wèn)題確實(shí)由 git 引起。大概是?go get?拉取模塊時(shí)，會(huì)先創(chuàng)建一個(gè)裸倉(cāng)庫(kù)，然后?add origin?。問(wèn)題就發(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è)倉(cāng)庫(kù)的?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

試想這么一種場(chǎng)景，假設(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 的上場(chǎng)。直接修改 go.mod 文件，添加：replace a => a v1.0.0?即可。

但是實(shí)際情況，往往會(huì)更復(fù)雜。比如 b 需要 a v2.0.0?的一些新特性的話，簡(jiǎn)單的?replace?往往不能解決這個(gè)問(wèn)題。如何解決呢？自己去處理。比如，Kuma^[1]?自己維護(hù)了一個(gè)?vendored?文件夾?replace?到本地來(lái)處理這種問(wèn)題；Kubernetes^[2]?也有個(gè)自己的?staging。

mod cache

需要注意的是 go 1.12 版本之前，mod cache 并不是并發(fā)安全的，同一個(gè)環(huán)境并發(fā)構(gòu)建可能會(huì)產(chǎn)生競(jìng)態(tài)。而最新的 go 1.15 還提供了環(huán)境變量?GOMODCACHE?來(lái)指定 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

推薦閱讀

• 如何使用私有倉(cāng)庫(kù)的 Go Modules