为什么用vendor目录
依赖问题
我们知道，一个工程稍大一点，通常会依赖各种各样的包。而Go使用统一的GOPATH管理依赖包，且每个包仅保留一个版本。而不同的依赖包由各自的版本工具独立管理，所以当所依赖的包在新版本发生接口变更或删除时，会面临很多问题。
为避免此类问题，我们可能会为不同的工程设置不同的GOPATH，或者更改依赖包路径名称。这样手动维护起来也很头疼。
解决方式
如果我们已经使用GOPATH去存储packages了，问什么还需要使用vendor目录呢？这是为了解决同一个包不同版本之间依赖问题。
假如多个应用使用一个依赖包的不同版本？这个问题不只是Go应用，其他语言也会有这个问题。
vendor目录允许不同的代码库拥有它自己的依赖包，并且不同于其他代码库的版本，这就很好的做到了工程的隔离。
常用的依赖包管理工具有godep，govendor等，这里选择vendor作为golang中的包管理工具。
Go 1.5引入了vendor文件夹，其对语言使用，go命令没有任何影响。若某个路径下边包含vendor文件夹，则在某处引用包时，会优先搜索vendor文件夹下的包。
在Go 1.5开启该项特性需设置GO15VENDOREXPERIMENT=1，而从Go 1.6开始，该项特性默认开启。vendor在go build时能够将应用搜索路径调整成为 “当前项目目录/vendor目录”的方式。通过这种形式，可以实现类似于 godep 方式的项目依赖管理。
注意：即使在项目中已经使用了vendor，该项目及vendor文件夹路径也必须在GOPATH中。在go项目及其工具链中，目前是逃不掉GOPATH的。
安装与简单使用
安装
使用go get命令即可实现快速安装。
|
1 |
go get -u github.com/kardianos/govendor |
使用说明
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#进入到项目目录 cd /Users/username/go/src/goproject #初始化vendor目录 govendor init #使用ls查看goproject项目下的目录，可以看到已经生成了vendor目录 ls cache cmd comman database main.go model service utils vendor #这里是ls命令返回的结果 #vendor会将GOPATH中本工程使用到的依赖包自动移动到vendor目录中 #说明：如果本地GOPATH没有依赖包，先go get安装相应的依赖包，然后使用下面命令添加进vendor目录 govendor add +external 或使用缩写： govendor add +e |
请注意,如果输入命令提示govendor这个命令没有找到,请自行将Gopath下/bin目录中的govendor.exe文件添加进环境变量
并且govendor命令请在goPath下执行
由两个箭头可以得知,main这个项目依赖以下包
①所以我们在main下执行命令,govendor init
这一步会生成vendor目录,vendor目录下有个vendor.json文件会记录依赖包名
②此时执行govendor add +e
别忘了add后面有一个空格,不能写成add+e
此时vendor.json中就会记录我们的包依赖信息如下图所示
常用命令
govendor [command]
| 命令 | 功能 |
| init | 初始化 vendor 目录 |
| list | 列出所有的依赖包 |
| add | 添加包到 vendor 目录,如 govendor add +external 添加所有外部包 ( govendor add +external 可以缩写成govendor add +e ) |
| add PKG_PATH | 添加指定的依赖包到 vendor 目录 |
| get | 类似 go get 命令，拉取依赖包到 vendor 目录 |
| update | 从 $GOPATH 更新依赖包到 vendor 目录 |
| remove | 从 vendor 管理中删除依赖 |
| status | 列出所有缺失、过期和修改过的包 |
| fetch | 添加或更新包到本地 vendor 目录 |
| sync | 本地存在 vendor.json 时候拉取依赖包，匹配所记录的版本 |
| migrate | 从原有工具中移动包到带有元数据的vendor文件夹 |
兰陵美酒郁金香
大道至简 Simplicity is the ultimate form of sophistication.
文章评论（0）