原文地址:http://www.gaoxuan1989.com/2017/07/10/golang-vendor-mange-dependices/
Vendor目录介绍
随着Go 1.5 release版本的发布,vendor目录被添加到除了GOPATH
和GOROOT
之外的依赖目录查找的解决方案。在Go 1.6之前,你需要手动的设置环境变量GO15VENDOREXPERIMENT=1
才可以使Go找到Vendor目录,然而在Go 1.6之后,这个功能已经不需要配置环境变量就可以实现了。
Note,即使使用vendor,也必须在
GOPATH
中,在go的工具链中,你逃不掉GOPATH
的
那么查找依赖包路径的解决方案如下:
- 当前包下的
vendor
目录。 - 向上级目录查找,直到找到src下的
vendor
目录。 - 在
GOPATH
下面查找依赖包。 - 在
GOROOT
目录下查找
一些建议
在使用vendor中,给出如下建议:
- 一个库工程(不包含
main
的package)不应该在自己的版本控制中存储外部的包在vendor\
目录中,除非他们有特殊原因并且知道为什么要这么做。 - 在一个应用中,(包含
main
的package),建议只有一个vendor
目录在代码库一级目录。
上面建议的原因如下:
- 在目录结构中的每个包的实例,即使是同一个包的同一个版本,都会打到最终的二进制文件中,如果每个人都单独的存储自己的依赖包,会迅速导致生成文件的二进制爆发(binary bloat)
- 在一个目录的某个pacage类型,并不兼容在同一个package但是在不同目录的类型,即便是同一个版本的package,那意味着loggers,数据库连接,和其他共享的实例都没法工作。
举个例子
工程目录如下:
- $GOPATH/src/github.com/mattfarina/golang-broken-vendor
- foo.go
- vendor/
- a/
- b/
- vendor/a/
在这个例子中,两个a
package都是完全一样的,b package在代码库中保存了a package,在顶级应用代码中也引用了a包。
文件foo.go
做了很简单的事情:
func main() {
var it a.A
it = "foo"
b.Do(it)
}
那么问题来了,当我们build的时候,发现出问题了,返回了下面的错误:
$ GO15VENDOREXPERIMENT=1 go build
./foo.go:12: cannot use it (type "github.com/mattfarina/golang-broken-vendor/vendor/a".A) as type "github.com/mattfarina/golang-broken-vendor/vendor/b/vendor/a".A in argument to b.Do
你可以clone这个测试工程到本地重现。
为什么用vendor目录
如果我们已经使用GOPATH
去存储packages了,问什么还需要使用vendor
目录呢?这是一个很实战的问题。
假如多个应用使用一个依赖包的不同版本?这个问题不只是Go应用,其他语言也会有这个问题。
vendor
目录允许不同的代码库拥有它自己的依赖包,并且不同于其他代码库的版本,这就很好的做到了工程的隔离。
推荐
我们发现Glide是非常好的包管理解决方案,他将依赖包平展开存放在顶级vendor
目录中,如果一个包被另一个程序引用了,那么这个包最好不要存储外部依赖项。如果使用Glide,你可以在glide.yml
文件中指定依赖包,Glide会帮你管理,并使用正确的版本。
网友评论
1、当前包下的vendor目录。
2、向上级目录查找,直到找到src下的vendor目录。
3、在GOPATH下面查找依赖包。
4、在GOROOT目录下查找
--------------
3和4的顺序是不是反了?