golang使用vendor目录来管理依赖包

0.088字数 840阅读 37315

原文地址:http://www.gaoxuan1989.com/2017/07/10/golang-vendor-mange-dependices/

Vendor目录介绍

随着Go 1.5 release版本的发布,vendor目录被添加到除了GOPATHGOROOT之外的依赖目录查找的解决方案。在Go 1.6之前,你需要手动的设置环境变量GO15VENDOREXPERIMENT=1才可以使Go找到Vendor目录,然而在Go 1.6之后,这个功能已经不需要配置环境变量就可以实现了。

Note,即使使用vendor,也必须在GOPATH中,在go的工具链中,你逃不掉GOPATH

那么查找依赖包路径的解决方案如下:

  • 当前包下的vendor目录。
  • 向上级目录查找,直到找到src下的vendor目录。
  • GOPATH下面查找依赖包。
  • GOROOT目录下查找

一些建议

在使用vendor中,给出如下建议:

  1. 一个库工程(不包含main的package)不应该在自己的版本控制中存储外部的包在vendor\目录中,除非他们有特殊原因并且知道为什么要这么做。
  2. 在一个应用中,(包含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

我们发现Glide是非常好的包管理解决方案,他将依赖包平展开存放在顶级vendor目录中,如果一个包被另一个程序引用了,那么这个包最好不要存储外部依赖项。如果使用Glide,你可以在glide.yml文件中指定依赖包,Glide会帮你管理,并使用正确的版本。

推荐阅读更多精彩内容