关于Go 包管理

 

PS：原创文章，如需转载，请注明出处，谢谢！     

本文地址：https://www.iteye.com/blog/flyer0126-2512110

 

0、包管理的历史

Golang 的包管理一直被大众所诟病的一个点，但是我们可以看到现在确实是在往好的方向进行发展。

下面是官方的包管理工具的发展历史：

• 在 1.5 版本之前，所有的依赖包都是存放在 GOPATH 下，没有版本控制。这个类似 Google 使用单一仓库来管理代码的方式。这种方式的最大的弊端就是无法实现包的多版本控制，比如项目 A 和项目 B 依赖于不同版本的 package，如果 package 没有做到完全的向前兼容，往往会导致一些问题。
• 1.5 版本推出了 vendor 机制。所谓 vendor 机制，就是每个项目的根目录下可以有一个 vendor 目录，里面存放了该项目的依赖的 package。go build 的时候会先去 vendor 目录查找依赖，如果没有找到会再去 GOPATH 目录下查找。
• 1.9 版本推出了实验性质的包管理工具 dep，这里把 dep 归结为 Golang 官方的包管理方式可能有一些不太准确。关于 dep 的争议颇多，比如为什么官方后来没有直接使用 dep 而是弄了一个新的 modules，具体细节这里不太方便展开。
• 1.11 版本推出 modules 机制，简称 mod，也就是本文要讨论的重点。modules 的原型其实是 vgo，关于 vgo，可以参考文章末尾的参考链接。https://research.swtch.com/vgo

 

1、go mod是什么？

go mod 是Golang 1.11 版本引入的官方包（package）依赖管理工具，用于解决之前没有地方记录依赖包具体版本的问题，方便依赖包的管理。

之前Golang 主要依靠vendor和GOPATH来管理依赖库，vendor相对主流，但现在官方更提倡go mod。

总结一下：

• 从go 1.11开始支持
• 可以不需要gopath存在
• 环境变量GO111MODULE，默认为auto
• 项目存在go.mod则使用go module,否则使用GOPATH和vendor机制

 

2、依赖管理

1）为什么需要依赖？

      我们想复用已有的工作成果。

将已有的工作成果加入我们项目中作为依赖存在太多的不确定性：

      包API的变化；包内部行为变化；包的依赖会变化；包已经不存在或无法访问；包与包之间的不同依赖相互冲突等

      随着软件开发规模的逐步增大，涉及到的外部依赖越来越多，手动管理的所有依赖愈发不可能。所以我们需要依赖管理，我们需要有个工具或者规范来描述和定义包与包之间的依赖关系，并自动化的去处理、解析和满足这些依赖。

 

3、基本使用

1）环境准备

Golang 版本：1.12.3。在 1.12 版本之前，使用 Go modules 之前需要环境变量 GO111MODULE:

• GO111MODULE=off: 不使用 modules 功能。
• GO111MODULE=on: 使用 modules 功能，不会去 GOPATH 下面查找依赖包。
• GO111MODULE=auto: Golang 自己检测是不是使用 modules 功能。（默认）

 

2）初始化go module环境

带git的项目：go mod init

不带git的项目：go mod init packagename

 

3）下载依赖包

只下载依赖包

    go mod download

拉取必须模块，移除不用的模块

    go mod tidy

 

注意点：

• 如果tag对应内容有更新，需要删除pkg中的缓存内容。

• cd $GOPATH/pkg/mod
  rm -rf *

• go get、go run、go build 也会自动下载依赖

 

4）添加新依赖包

方法一：直接修改go.mod，然后执行:go mod download

方法二：使用go get packagename@v1.2.3，会自动更新 go.mod 文件

方法三：go run、go build也会自动下载依赖

 

5）将依赖包下载到vendor目录

go mod vendor

注意：只会下载对应版本的包文件，不会下载所有版本

 

4、总结

1）大部分场景 go mod init 和 go mod tidy就够了

2）查看$GOPATH/pkg/mod里面的文件就知道了，mod做了一件类似maven的事把所有包都打上了版本号。

    解决多版本问题困扰。