因为之前一直是 C++ Coder,根本没有所谓的包管理,项目依赖一塌糊涂,说到 C++ 的不便之处还得吐槽一句,编译速度贼慢,每次项目中写完代码等待编译的时候就想着,以后再也不想用 C++ 写代码了。
说回正题,go mod 包管理工具
没有包管理之前,项目管理会出现什么问题
在没有包管理方案之前,项目依赖于 GOPATH,这样带来一些不便之处:
多项目难以管理。试想一下,A 项目和 B 项目 同时依赖于一个 C 项目,但是依赖于 C 项目的不同版本,如何解决,只能通过多 GOPATH 设置。
项目的依赖只能够手动 go get 下载到 GOPATH 中,如果换一台服务器开发项目,光是包依赖都得弄半天。
go mod 出来之前,其他方案的是怎么设计的?
godep,glide,go verdor 这些都是曾经出现过的包管理解决方案。
挑 go vendor 说一下,他是如何解决上面的两个问题的。
对于多项目,他是在项目中创建一个文件夹 vendor,将项目的依赖都放在里面,这样就实现了多项目分开管理依赖。
对于手动下载包,他会将项目依赖的信息和版本统一记录在一个文件中,这样迁移环境只需要执行特定命令就能将依赖包都下载到 vendor 文件夹中
在 go mod 出来之前,go vendor 包管理模式是受很多大牛推崇的,也是非常好的方案。
当然也有一点小瑕疵:
- 多个项目都依赖于同版本的 A 项目,则 A 项目需要冗余存储多份。
go mod 是怎么设计的?
既然 go vendor 已经成熟了,为什么不直接扶正呢,因为 google 爸爸有自己的想法。
这就是我们今天的重点 go mod 包管理方案。
go mod 和 go vendor 类似,有统一的目录管理包依赖,但是是统一放在 $GOPATH/pkg/mod 里面,对于多版本管理见下图。
和 go vendor 一样,项目中有文件记录项目的包依赖和版本号,go.mod 和 go.sum
go mod 使用篇
常用命令:
go mod graph 把模块之间的依赖图显示出来
go mod init 初始化模块(例如把原本dep管理的依赖关系转换过来)
go mod tidy 增加缺失的包,移除没用的包
go mod vendor 把依赖拷贝到 vendor/ 目录下
go mod verify 确认依赖关系
go mod why 解释为什么需要包和模块
go mod 启用的三种模式
- on:开启 Go mod 模式
- off:关闭 Go mod 模式
- auto (默认模式):如果代码在gopath下,则自动使用gopath模式;如果代码不在gopath下,则自动使用GO mod模式。
大陆额外福利
经常会有一些包,比如 golang.org/x/net 等,无法直接下载。
只需要添加环境变量即可
export GOPROXY=https://goproxy.io
一起愉快的用 go mod 吧
使用例子:
初识RPC
示例代码地址 go-micro-demo
有疑问加站长微信联系(非本文作者)