0. 前言
- 最近加入鹅厂学习 k8s，组内使用 Go 1.11 以上的 go modules 管理依赖，因此整理了相关资料
- 本文严重参考原文：初窥Go module
1. 传统 Golang 包依赖管理
-
Golang 设计深受 Google 主干开发模型影响：
- 所有开发人员基于主干 trunk/mainline 开发：提交到 trunk 或从 trunk 获取最新的代码（同步到本地 workspace）
- 版本发布时，建立 Release branch，release branch 实质上就是某一个时刻主干代码的快照
- release branch 上 的 bug fix 和增强改进代码也通常是先在主干上提交（commit），然后再 cherry-pick 到 release branch 上
- Golang 中的 go get 的设计深受 Google 内部单一代码仓库（single monorepo）和基于主干（trunk/mainline based）的开发模型的影响：只获取 trunk/mainline 最新版本
- go get 获取的代码会放在 $GOPATH/src 下面，而 go build 会在 $GOROOT/src 和 $GOPATH/src 下面按照 import path 去搜索 package
- 由于 go get 获取的都是各个 package repo 的 trunk/mainline 的代码，因此 Go 1.5 之前的 Go compiler 都是基于目标 Go 程序依赖包的 trunk/mainline 代码去编译的
- 这样的机制带来的问题包括：
- trunk/mainline 代码时刻变化，不同人不同时刻获取的代码可能不同（即不能实现 reproduceable build）
- 依赖包的 trunk 演进可能会导致代码无法编译
- 为了实现 reporduceable build，Go 1.5 引入了 govendor 机制
- Golang 编译器会优先在 vendor 下搜索依赖的第三方包
- 开发者将特定版本的依赖包存放在 vendor 下面并提交到代码库
- 那么所有人理论上都会得到同样的编译结果，从而实现reporduceable build
- 在Go 1.5 发布后的若干年，Gopher 们把注意力都集中在如何利用 vendor 解决包依赖问题
- 从手工添加依赖到 vendor
- 手工更新依赖，到一众包依赖管理工具的诞生：比如: govendor、glide 以及号称准官方工具的 dep
- 努力地尝试着按照当今主流思路解决着诸如：“钻石型依赖”等难题
- 正当 Gopher 认为 dep 将顺理成章地升级为 go toolchain 一部分的时候，vgo 横空出世
- 在原 Go tools 上简单快速地实现 了Go 原生的包依赖管理方案 ，vgo 就是 go modules 的前身
2. go modules 简介
- 通常我们会在一个仓库中创建一组 package，仓库的路径比如：github.com/bigwhite/gocmpp 会作为 go package 的导入路径（import path）
- GOPATH 模式下，编译器会根据 package 路径在 $GOPATH/src 或者 vendor 下逐级目录匹配
- Go 1.8 版本中，如果开发者没有显式设置 $GOPATH，Go 会赋予 GOPATH 一个默认值（在 linux 上为 $HOME/go）
- Go 1.11 给这样的一组在同一仓库下面的 packages 赋予了一个新的抽象概念：module
- 并启用一个新的文件 go.mod 记录 module 的元信息
- 一个仓库对应一个 module 或者多个 module
- 在 go modules 下，仓库顶层目录下会放置一个 go.mod 文件，每个 go.mod 文件定义了一个 module，而放置 go.mod 文件的目录被称为 module root 目录（通常对应一个仓库的 root 目录，但不是必须的）
- module root 目录以及其子目录下的所有 packages 均归属于该 module，除了那些自身包含 go.mod 文件的子目录
- 在 go modules 下，Golang 编译器将不再在 GOPATH 下面以及 vendor 下面搜索目标程序依赖的第三方 packages
3. 尝试使用 go modules
- 设置环境变量 GO111MODULE：
- GO111MODULE=off：无模块支持，go 会从 GOPATH 和 vendor 文件夹寻找包
- GO111MODULE=on：模块支持，go 会忽略 GOPATH 和 vendor 文件夹，只根据 go.mod 下载依赖
- GO111MODULE=auto：在 $GOPATH/src 外面且根目录有 go.mod 文件时，开启模块支持
- 在使用模块的时候，GOPATH 是无意义的，不过还是会把下载的依赖储存在 $GOPATH/pkg/mod 中，也会把 go install 的结果放在 $GOPATH/bin
- 在 ~/test 下创建 hello 目录，然后写入 hello.go（此时不在 $GOPATH 中）
// hello.go
package main
import "bitbucket.org/bigwhite/c"
func main() {
c.CallC()
}
-
在 ~/test/hello 下创建 go.mod：
// go.mod module hello
- 构建 hello.go：
$ go build hello.go
go: finding bitbucket.org/bigwhite/c v1.3.0
go: downloading bitbucket.org/bigwhite/c v1.3.0
go: extracting bitbucket.org/bigwhite/c v1.3.0
go: finding bitbucket.org/bigwhite/d v1.2.0
go: downloading bitbucket.org/bigwhite/d v1.2.0
go: extracting bitbucket.org/bigwhite/d v1.2.0
$ ./hello.exe
call C: v1.3.0
--> call D:
call D: v1.2.0
--> call D end
- 查看 go.mod：
$ cat go.mod // go.mod module hello go 1.12 require bitbucket.org/bigwhite/c v1.3.0 // indirect
- indirect 指不是由主 mod 直接引用的包，而是由其他 mod 间接引用的包
- 如果之后新增了该 mod 的直接引用，会删除上面的间接引用
- go compiler 将下载的依赖包缓存在 $GOPATH/pkg/mod 下面：
$ pwd /e/Coding/Golang/go/pkg/mod/cache/download $ ls bitbucket.org/ github.com/ golang.org/ gopkg.in/ sigs.k8s.io/ cloud.google.com/ go.uber.org/ google.golang.org/ k8s.io/
-
具体执行：
$ ./hello.exe
call C: v1.3.0
--> call D:
call D: v1.2.0
--> call D end
4. 参考文献
来源：https://www.cnblogs.com/wangao1236/p/11002871.html