Go-知识依赖Vendor
- 1. 介绍
- 2. vendor 目录位置
- 3. 搜索顺序
- 4. vendor 的不足
1. 介绍
自 Go 1.6 起,vendor 机制正式启用,它允许把项目的依赖放到一个位于本项目的 vendor 目录中,这个 vendor 目录
可以简单理解成私有的 GOPATH 目录。 项目编译时,编译器会优先从 vendor 中寻找依赖包,如果 vendor 中找不到,
则再到 GOPATH 中寻找。
2. vendor 目录位置
一个项目可以有多个 vendor 目录,分别位于不同的目录级别,建议每个项目只在根目录下放置一个 vendor 目录。
假如有一个 github.com/test/testcase
项目,项目目录结构如下:
GOPATH/src/github.com/test/testcase/testpackage/main/main.go
其中 main.go
中依赖如下几个包:
import ("golang.org/x/crypto/ssh""github.com/pkg/sftp"
)
在没有使用 vendor 目录时,若想编译这个项目,则 GOPATH 目录经过应该如下:
GOPATH/src/github.com/test/testcase/
GOPATH/src/github.com/pkg/sftp
GOPATH/src/golang.org/x/crypto/ssh
即所有依赖的包都位于 GOPATH/src 下。
为了把所使用到的 golang.org/x/crypto/ssh
和 github.com/pkg/sftp
版本固化下来,可以使用 vendor 机制。
在项目 github.com/test/testcase/
根目录下创建一个 vendor 目录,并把 golang.org/x/crypto/ssh
和 github.com/pkg/sftp
存放到此目录中,让其成为项目的一部分:
GOPATH/src/github.com/test/testcase/testpackage/main/main.go
GOPATH/src/github.com/test/testcase/vendor/github.com/pkg/sftp/
GOPATH/src/github.com/test/testcase/vendor/golang.org/x/crypto/ssh/
使用 vendor 的好处是在项目 github.com/test/testcase
发布时可以把其所依赖的软件一并发布,编译时不会受到 GOPATH 目录的影响,即便 GOPATH 下也有一个
同名但不同版本的依赖包。
3. 搜索顺序
编译器会从源码文件所在的目录开始逐级向上搜索,在上面的例子中,在编译 main.go
时,编译器搜索依赖包的顺序为:
- 从
GOPATH/src/github.com/test/testcase/testpackage/main/
下寻找 vendor 目录,没有找到,继续从上层查找。 - 从
GOPATH/src/github.com/test/testcase/testpackage/
下寻找vendor 目录,没有找到,继续从上层查找。 - 从
GOPATH/src/github.com/test/testcase/
下寻找 vendor 目录,从 vendor 目录中查找到依赖包,结束查找。
如果 GOPATH/src/github.com/test/testcase/
下的 vendor
目录中没有依赖包,则返回 GOPATH 目录继续查找。这就是 GOPATH 机制了。
实际上 vendor
目录可以存在于项目的任意目录下。但是不推荐,如果 vendor
目录过于分散,则可能同一个依赖包在项目的多个 vendor
中出现
多次,这样依赖包会多次编译进二进制文件,从而造成二进制文件的体积急剧增大,也很可能出现一个项目中使用同一个依赖包的多个版本的情况。
4. vendor 的不足
vendor
很好地解决了多项目间的隔离问题,但是也有一些不足之处:
- 项目依赖关系不清晰,无法清楚地看出
vendor
目录中依赖包的版本。 - 依赖包升级时很不方便审核。
更严重的是二进制文件的体积急剧增大的问题,比如项目依赖开源包A和B,但是A中也有一个vendor目录,其中也放了B,那么项目中将出现两个开源包B。
如果两个开源包B的版本不一致或者不兼容,那么后果非常可怕。
vendor
能够解决大部分项目中的问题,但是也存在很多的不足之处。