官方golang包管理神器,值得一试!go mod

2020年5月20日 评论 841 views 2814字阅读9分22秒

这是一篇很短的文章,诉说着高效的包管理工具 go mod

我们上次说过如何让一个项目在 Goland 编译器跑起来,但是要自己去下包,要花不少时间找包下包,是不是很麻烦?

java 里有一个叫 maven 的包管理工具, go 也有一个叫 go mod 的管理工具,可以管理项目引用的第三方包版本、自动识别项目中用到的包、自动下载和管理包。

怎么用?

找到你的项目,直接执行

go mod init main.go

执行完会自动识别项目中用到的第三方包,并生成一个 go.mod 文件

$ cat go.mod
module collector_go

go 1.14

require (
    github.com/gogo/protobuf v1.3.1 // indirect
    github.com/golang/protobuf v1.4.2
    google.golang.org/protobuf v1.23.0
)

然后直接 buildrun 就会自动下载包啦~!

go build -o ./collector_go main.go

有一个小前提

golang>=1.12
添加环境变量 GO111MODULEon 或者 auto ,设置方法

go env GO111MODULE=on

他解决了什么问题?

原来的包管理方式

  • 在不使用额外的工具的情况下,Go 的依赖包需要手工下载,
  • 第三方包没有版本的概念,如果第三方包的作者做了不兼容升级,会让开发者很难受
  • 协作开发时,需要统一各个开发成员本地$GOPATH/src下的依赖包
  • 引用的包引用了已经转移的包,而作者没改的话,需要自己修改引用。
  • 第三方包和自己的包的源码都在src下,很混乱。对于混合技术栈的项目来说,目录的存放会有一些问题

新的包管理模式解决了以上问题

  • 自动下载依赖包
  • 项目不必放在$GOPATH/src内了
  • 项目内会生成一个go.mod文件,列出包依赖
  • 所以来的第三方包会准确的指定版本号
  • 对于已经转移的包,可以用 replace 申明替换,不需要改代码

tips

Q1: 我的包下哪去了?

A: 依赖的第三方包被下载到了 $GOPATH/pkg/mod 路径下。

Q2: GO111MODULE 的三个参数 autoonoff 有什么区别?

A: auto 根据是否在 src 下自动判定, on 只用 go.modoff 只用 src

Q3: 依赖包中的地址失效了怎么办?比如 golang. org/x/… 下的包都无法下载怎么办?

A: 在 go.mod 文件里用 replace 替换包,例如

replace golang.org/x/text => github.com/golang/text latest

这样, go 会用 github.com/golang/text 替代 golang.org/x/text

Q4: 在 go mod 模式中,项目自己引用自己中的某些模块怎么办?

A: go.mod 文件里的第一行会申明 module main ,把这个 main 改为你的项目名,引用的时候就 import "项目名/模块名" 即可。

根据官方的说法,从 Go 1.13 开始,模块管理模式将是 Go 语言开发的默认模式

包依赖是怎么查找的?

  • Go 语言在多个工作区中查找依赖包的时候是以怎样的顺序进行的?
  • 如果在多个工作区中都存在导入路径相同的代码包会产生冲突吗?
  • 归档文件是什么
  • 正规的go项目的文件分层和路径是怎么划分的?

Go 语言在多个工作区中查找依赖包的时候是以怎样的顺序进行的?这个问题很重要,不然常常都会找不到包

go分为一般模式和mod模式

对于一般模式,go语言从v1.5开始开始引入vendor模式,首先会在项目根目录下的vendor文件夹中查找,如果没有找到就会去$GOAPTH/src目录下查找。

而vendor的查找顺序是
1. 从引用文件所在的vendor路径下面搜索,
2. 如果没有找到,那么从上层目录的vendor路径下面搜索,
3. 直到src的vendor路径下面搜索。

GO111MODULE=off的时候完整过程是

  1. 优先使用vendor目录下面的包,
  2. 如果vendor下面没有搜索到,再搜索$GOPATH/src下面的包,
  3. 如果$GOPATH下面没有搜索到,那么搜索$GOROOT/src下面的包,
  4. 要么完整使用vendor下面的包,要么完整使用$GOPATH下面的包,不会混合使用。

在golang>=1.12的版本是默认使用go mod的,是auto的模式,也就是自动查找

  1. 编译时编译器会从工作目录(当前所在目录)开始并逐级向上查找是否具有 go.mod 文件。
  2. 如果有,go.mod 文件中声明的 module 名称就视作 go.mod 所在的路径,然后以指定的 main 包为依赖入口
    3.所有以 go.mod 中声明的 module 名称开头的导入路径都以 go.mod 所在的路径为相对路径进行包的查找导入。
    4.所有需要导入的路径中如果在 go.mod 中指定了版本,则从 $GOPATH/pkg/mod/ 下取得相应版本进行导入,如果没有被指定则从 $GOPATH/src/ 或 $GOROOT/src/ 中进行查找导入。

最后如果没有,就不使用go mod模式,所有依赖均从 $GOPATH/src/ 或 $GOROOT/src/ 中进行查找导入。

如果GO111MODULE=on时,那么就会直接强制使用modules功能

这种模式下,$GOPATH不再作为build时导入的角色,依赖包会存放在$GOPATH/pkg/mod目录下。工程中的依赖包也会从此目录下查找.

那么又是mod又有vendor呢?

可以用这个项目试验一下

GO111MODULE=on 启用 go module

mod虽好,但是费开发者的电脑磁盘,go mod拉取的软件包都会放在当前目录的pkg/mod目录下面,不像java的maven本地一个集中的目录。其实在go 1.13版本中,go mod下载依赖包目前是放在$GOPATH/pkg/mod目录下,所有项目是共享的。

只有当使用go mod vendor指令后,才会将当前所有依赖包拷贝至当前项目目录下。

有什么好处?下载到vendor目录下,然后直接提交到仓库里,当前项目就可以随意拷贝分发,避免因网络问题造成接收者安装依赖包的麻烦。

所以如果go mod的包版本升级,要手动go mod vendor

go.sum是升级的产物吗?

然后我来到我的项目中,实际上还是使用的$GOPATH/pkg/mod,不会用vendor下的包,我把vendor包删除了,go build还是可以成功,所以对于go mod来说,vendor只是做一个传包的作用,这个是我实验得到的

go.sum 是自动生成的,我们不用管他

它的作用一个是校验,比如tag0.1被删除了,但是重新打一个tag还是0.1,是不一样的

还有就是我在网上查到的,作为 transparent log 来加强安全性,也就是一个历史依赖的日志

https://studygolang.com/articles/25658

参考掘金:https://juejin.im/post/5c9c8c4fe51d450bc9547ba1

weinxin
公众号
在号内与我交流,回复【资源】获取技术大礼包
Golang最后更新:2021-1-7
小熊