关于golang:记一次go-get安装hugo的坑go-modulegoinstallgobuild

该文章的 golang 版本为go version go1.14.5 darwin/amd64

心路历程

1. 报错

早晨原本想装个 hugo 玩玩，hugo 提供了挺多装置办法比方最间接的二进制包装置、homebrew 等包治理装置、docker，正好电脑里也有 golang 的环境，平时装 go 写的软件也很不便 go get 就解决了，自然而然想到go get -v github.com/gohugoio/hugo，看着控制台 Download 了半天最初居然给我报了个错：

package github.com/jdkato/prose/transform: cannot find package "github.com/jdkato/prose/transform" in any of:
        /usr/local/Cellar/go/1.14.5/libexec/src/github.com/jdkato/prose/transform (from $GOROOT)
        /Users/jabin/go/src/github.com/jdkato/prose/transform (from $GOPATH)

大略意思就是找不到 github.com/jdkato/prose/transform 这个包，我下意识点开 https://github.com/jdkato/prose/transform 一探到底，发现 github 的确报了 404 谬误，阐明这个包的确有点问题。

2. 尝试

而后我寻思着不对劲怎么装都装不上，关上 hugo 的 github 仓库看到了这样的向导：

mkdir $HOME/src
cd $HOME/src
git clone https://github.com/gohugoio/hugo.git
cd hugo
go install

我不信邪，就试了一下先 clone 再go install会怎么样，而后发现居然胜利了，在 golang 的 bin 目录（在我的电脑下是 ~/go/bin）下生成了一个名为hugo 的可执行文件。

3. 排错

我寻思着 go get 是把我的项目先拉下来而后编译放在 ~/go/bin 下，go install是本人手动进入了某个我的项目目录下执行编译输入到 ~/go/bin，二者应该只有 本人把我的项目拉下来而后进入该我的项目 的区别，怎么会呈现这样奇怪的谬误。

3.1 灵异事件

一遍思考一遍手上又执行了一遍 go get -v github.com/gohugoio/hugo，这一遍居然什么报错也没有，我连忙删掉~/go/bin 下的编译产物 hugo，测验是否真的go get 可能失常编译出可执行文件了，后果是 的确没有报错且失常编译出后果了。

我百思不得其解，然而回忆一开始失去的谬误，仿佛谬误中提到了两个门路：

• /usr/local/Cellar/go/1.14.5/libexec/src/github.com/jdkato/prose/transform (from $GOROOT)
• /Users/jabin/go/src/github.com/jdkato/prose/transform

我逐个查看后发现的确两个地址都无奈找到须要的这个包，于是我开始想这个我的项目是不是有什么问题，相熟 go 包和 github 地址的人应该分明，这个地址阐明这个包的作者是 jdkato，我的项目名是prose，transform 应该是我的项目下的一个文件夹。

3.2 计算机不会耍赖皮

写文章时 https://github.com/jdkato/prose 的最新 commit 是c2b2f78b870e41bec89843648b04b1716a0fb9c6
hugo 的 github 仓库的最新 commit 是c84ad8db821c10225c0e603c6ec920c67b6ce36f

于是我开始在 github 搜 jdkato 这个名字，发现了这个作者的确有 prose 这个我的项目 https://github.com/jdkato/prose，点进去一看发现这个我的项目也的的确确没有 transform 这个文件夹。

再翻看 hugo 的 github 仓库发现最新的 release 是三天前，阐明 hugo 的代码自身没有什么问题。

这时候我得出一种推论，hugo 可能用了 prose 这个我的项目的老版本，老版本里存在 transform 这个文件夹，hugo 可能是本人的 golang 环境里缓存了 prose 这个我的项目的老版本之类的。然而很快这种想法就被我本人颠覆了，因为我的的确确在本人的电脑上 go install 胜利了 hugo 的最新源码，并且在 go install 胜利之前我还处于 package github.com/jdkato/prose/transform: cannot find 的谬误中，基本不存在缓存了老版本我的项目代码的可能。

3.3 假相只有一个

揣测到这里，我想起来一个重要的货色，go.mod正是那个 能够缓存旧版本的 关键人物啊！我连忙再翻看 hugo 的 github 仓库，果然发现了 go.mod 这个文件，外面也有这样一段记录：

module github.com/gohugoio/hugo

require (
    ... 省略
    github.com/jdkato/prose v1.2.0
    ... 省略
)

replace github.com/markbates/inflect => github.com/markbates/inflect v0.0.0-20171215194931-a12c3aec81a6

go 1.12

能够看到 require 中指出了对我的项目 github.com/jdkato/prose 的版本要求为 v1.2.0，我啪的一下就关上了 https://github.com/jdkato/prose/tree/v1.2.0，果然在v1.2.0 这个旧版本的 tag 下有咱们想要的 transform 文件夹。

那么 go get 报错的假相就只有一个，go get获取了最新版本的 github.com/jdkato/prose，正好最新版本的github.com/jdkato/prose 重构了，我的项目构造产生了扭转。而 go install 胜利后 go get 也能胜利的灵异事件也能说的过来了，就是因为 go install 获取到了对的版本的我的项目，导致 go get 也可能找到须要的文件了。

3.4 案件远没有完结

只管得出了一个看起来说的过来的解释，然而问题又来了：为什么 go install 就能获取到对应的版本的我的项目？

我自然而然想到了 go.mod 这个关键人物，我同样得出一个大胆的推论：go get不会理睬 go.mod 中的限度，而 go install 则会在意。

3.5 口说无凭，怎么证实

粗略了翻阅了无关 go get 和go install的一些阐明，发现没什么和我这个问题相干的，只好来点硬核的了，正好 go 也是自举的，go 语言的 go 语言源码还是能够看看的。

3.6 源码中的线索

git clone https://github.com/golang/go.git
cd go
code .

上来间接一个闪电三连码，用命令行关上我习惯的 vscode 开始看。

通过搜寻找到了 go get 和go install的源码，别离位于

为什么 go install 不是在 install.go 里？依据我的察看，因为 go install 和 go build 的性能和实现都很靠近，所以这两个命令的源码都在 /go/internal/work/build.go。

次要看看 get.go 的源码，外面有一个 runGet 办法，这是执行 go get 的入口办法，该办法中存在这样的调用链：
load.PackagesForBuild->PackagesAndErrors->ImportPaths

这个 ImportPaths 办法残缺如下：

func ImportPaths(args []string) []*search.Match {if ModInit(); cfg.ModulesEnabled {return ModImportPaths(args)
    }
    return search.ImportPaths(args)
}

可一看到源码中对于 ModInit(); cfg.ModulesEnabled 是否成立有两种解决模式。

3.7 要害信息

因为源码里对于 ModInit() 只是简略的 var ModInit func()，没有办法体能够看到，兴许是再别的中央进行了实现，我也没有深究。次要是看到了cfg.ModulesEnabled 这个变量，间接想到了 go module 是否失效的问题，于是百度了 go module 并且看到了这篇文章(https://www.cnblogs.com/chnmig/p/11806609.html)，外面有这样一段话：

go 在 1.13 版本默认是 auto,代表 当我的项目在 GOPATH/src 外且我的项目根目录有 go.mod 文件时，开启 go module. 也就是说, 如果你不把代码搁置在 GOPATH/src 下则默认应用 MODULE 治理.
不好意思看错了,1.13+ 的版本判断开不开启 MODULE 的根据是根目录下有没有 go.mod 文件
咱们也可手动更改为 on(全副开启)/off(全副不开启)

我豁然开朗，因为我 go get 的中央正好就是轻易一个中央 -> 没有在我的项目里 -> 天然没有 go.mod-> 也就没有开启module->ModInit(); cfg.ModulesEnabled 不成立 ->go get源码进入了另一种解决形式 ->hugo 源码中的 go.mod 没有失效，所有都解释的通了。

3.8 验证

验证的办法也很简略，依据前文的判断要害，新建一个有 go.mod 的环境再执行一次 go get 就能够了。

mkdir testgo
cd testgo 
go mod init xxx
go: creating new go.mod: module xxx
go get -v github.com/gohugoio/hugo

在有 go.mod 存在的环境下是能够装置胜利的，也证实了后面的说法，至此所有都解决了。

4. 结尾

这次的问题也花了一整个下午的工夫去排查，先是花了一些工夫思考可能的起因，又花了很长时间去看源码，读源码真的花了很长很长的工夫，一连看了几个小时直到头都有些晕了在起身去吃饭，吃完饭回来有精力了持续看了一会就发现问题了，可能在文章中就是简略的调用链路和几行要害代码，然而怎么在上千行的源码中找到这些要害信息远没有文章中的那么简略，首先是要看懂，而后是顺着调用链往下持续看懂，有时候还会误会而后找错方向找了很久……

但后果还是十分好的，解决了本人的纳闷，更难能的是在源码里学到了几个很有意思很妙的写法，比方这两个：

// 这个 else if 的程序和作用域利用的很充沛
func CleanPatterns(patterns []string) []string {
    // 省略
    var out []string
    for _, a := range patterns {
        var p, v string
        if build.IsLocalImport(a) || filepath.IsAbs(a) {p = a} else if i := strings.IndexByte(a, '@'); i < 0 {p = a} else {p = a[:i]
            v = a[i:]
        }
        // 省略
     }
     // 省略
}

// 匿名函数 + 函数变量 + 递归 + 闭包的妙用
func PackageList(roots []*Package) []*Package {seen := map[*Package]bool{}
    all := []*Package{}
    var walk func(*Package)
    walk = func(p *Package) {if seen[p] {return}
        seen[p] = true
        for _, p1 := range p.Internal.Imports {walk(p1)
        }
        all = append(all, p)
    }
    for _, root := range roots {walk(root)
    }
    return all
}

写的有点长了，但还是想残缺的记录一下心路历程，折腾的过程还是很有意思的。