首先关于vendor

1 提出问题

我们知道，一个工程稍大一点，通常会依赖各种各样的包。而Go使用统一的GOPATH管理依赖包，且每个包仅保留一个版本。而不同的依赖包由各自的版本工具独立管理，所以当所依赖的包在新版本发生接口变更或删除时，会面临很多问题。

为避免此类问题，我们可能会为不同的工程设置不同的GOPATH，或者更改依赖包路径名称。这样手动维护起来也很头疼。

2 解决问题

Go 1.5引入了vendor文件夹，其对语言使用，go命令没有任何影响。若某个路径下边包含vendor文件夹，则在某处引用包时，会优先搜索vendor文件夹下的包。

在Go 1.5开启该项特性需设置GO15VENDOREXPERIMENT=1，而从Go 1.6开始，该项特性默认开启。

3 使用方式

3.1 vendor搜索方式

vendor包的搜索方式为：自包引用处，从其所在文件夹查询是否有vendor文件夹包含所引用包；若没有，然后从其所在文件夹的上层文件夹寻找是否有vendor文件夹包含所引用包，若没有，则再搜索上层文件夹的上层文件夹...，直至搜索至$GOPATH/src并搜索完成时止。
例如，如下代码中，`$GOPATH/src/x/y/z/main.go引用了包"v"，则不论vendor/v/v.go`置于src/，src/x/，src/x/y/，src/x/y/z/中任意一个文件夹下，均可以找到。

$ cat $GOPATH/src/x/y/z/main.go

package main

import (

    "v"

)

func main() {

    v.V()

}

$ cat vendor/v/v.go

package v

import "fmt"

func V() {

    fmt.Println("I'm a vendor test")

}

$ go run main.go

I'm a vendor test

当vendor存在嵌套时，若不同的vendor文件夹包含相同的包，且该包在某处被引用，寻找策略仍遵循如上规则。即从包引用处起，逐层向上层文件夹搜索，首先找到的包即为所引，也就是从$GOPATH/src来看，哪个vendor包的路径最长，使用哪个。

如下代码中，$GOPATH/src/x/y/z/main.go所在工程有两个vendor文件夹（分别位于$GOPATH/src/x/vendor/v/，$GOPATH/src/x/y/z/vendor/v/）包含相同的包"v"，目录树为：

$ tree $GOPATH/src

src

 └ x

   ├ vendor

   │  └ v

   │     └ v.go

   └ y

     └ z

       ├ vendor

       │ └ v

       │    └ v.go

       └ main.go

$ cat $GOPATH/src/x/vendor/v/v.go

package v

import "fmt"

func V() {

    fmt.Println("I'm a vendor test, My path is x/vendor/v/")

}

$ cat $GOPATH/src/x/y/z/vendor/v/v.go

package v

import "fmt"

func V() {

    fmt.Println("I'm a vendor test, My path is x/y/z/vendor/v/")

}

输出为：

$ go run main.go

I'm a vendor test, My path is x/y/z/vendor/v/

可以看到，真正调用的是$GOPATH/src/x/y/z/vendor/v/v.go。

3.2 vendor使用规约

使用vendor时，建议遵循如下两条规约。

a) 当欲将某包vendor时，可能想将所有依赖包均vendor；
b) 尽量将vendor依赖包结构扁平化，不要vendor套vendor。

如下示例代码演示vendor扁平化使用。

main.go位于$GOPATH/src/github.com/olzhy/test下。

package main

import (

    "strings"

    "sync"

    "time"

    "github.com/z"

    "github.com/y"

    "golang.org/z"

)

...

$GOPATH/src/github.com/olzhy/test目录树。

├─ main.go

└─ vendor

    ├─ github.com

    │   ├─ x

    │   └─ y

    └─ golang.org

         └─ z

参考资料

[1] https://go.googlesource.com/proposal/+/master/design/25719-go15vendor.md

[2] https://blog.gopheracademy.com/advent-2015/vendor-folder/

[3] https://tonybai.com/2015/07/31/understand-go15-vendor/

转自:

https://leileiluoluo.com

接下来是关于dep

dep 是 golang 项目依赖管理之一，是官方的实验项目，目前更新很频繁处于高速发展期，所以选 dep 作为 golang 的依赖管理器是比较靠谱的。（已知 glide 仅支持不再开发新功能）

目前 dep v0.5.0 release 已经发布，最新的 changelog 显示只支持 golang 1.9+ 以上的版本

golang 最原始的依赖管理是 go get ，执行命令后会拉取代码放入 src 下面，但是它是作为 GOPATH 下全局的依赖，并且 go get 还不能版本控制，以及隔离项目的包依赖在没有依赖管理工具的时候，golang 项目有一种目录结构比较流行如下：

.

└── src

    ├── demo

    │   └── main.go

    ├── github.com

    ├── golang.org

    └── gopkg.in

这样做的话就是每一个项目一个 GOPATH 则上面的 GOPATH=/xx/xx/src 这样设置后也是可以编译的，且项目依赖都是 src 下的包，与全局的无关联， go get 获取依赖，也必须在项目 GOPATH 下。可以看到这样的目录结构还是有很多缺陷的。特别是 import 包的包目录有时会很奇怪，没有统一的风格，且 ide 或编辑器支持也不够理想。

所以目前 golang 引入了 vendor 目录作为依赖管理目录，且 ide 或 golang 编辑插件目前都能很好的支持例如 gogland 索引依赖包时会优先查找项目根目录下的 vendor 目录， vscode 的 go 插件也是。那么目前比较流行的目录结构如下：

.

├── Gopkg.lock

├── Gopkg.toml

├── main.go

└── vendor

    ├── github.com

    │   ├── gin-contrib

    │   ├── gin-gonic

    │   ├── golang

    │   ├── mattn

    │   └── ugorji

    ├── golang.org

    │   └── x

    └── gopkg.in

        ├── go-playground

        └── yaml.v2

项目目录 $GOPATH/src/projectname/.

Getting Started

install / uninstall

brew install dep

brew uninstall dep

# /usr/local/bin/dep

windows

# 推荐 go get 安装

go get -u github.com/golang/dep/cmd/dep

# $GOPATH/bin/dep.exe

Arch linux

pacman -S dep

# 删除 pacman -R dep

二进制安装

curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh

# $GOPATH/bin/dep

# 删除 > rm $GOPATH/bin/dep

源码安装

go get -d -u github.com/golang/dep

cd $(go env GOPATH)/src/github.com/golang/dep

DEP_LATEST=$(git describe --abbrev=0 --tags)

git checkout $DEP_LATEST

go install -ldflags="-X main.version=$DEP_LATEST" ./cmd/dep

git checkout master

推荐安装方式为各系统的快捷安装，最方便且不容易出错，如果想使用最新/指定版本，推荐源码安装

初始化项目

推荐使用上述第二种目录结构

mkdir $GOPATH/src/example

cd $GOPATH/src/example

dep init

# 生成 vendor/ 目录下 Gopkg.toml Gopkg.lock

使用流程

Usage

Dep is a tool for managing dependencies for Go projects

Usage: "dep [command]"

Commands:

  init     Set up a new Go project, or migrate an existing one

  status   Report the status of the project's dependencies

  ensure   Ensure a dependency is safely vendored in the project

  prune    Pruning is now performed automatically by dep ensure.

  version  Show the dep version information

Examples:

  dep init                               set up a new project

  dep ensure                             install the project's dependencies

  dep ensure -update                     update the locked versions of all dependencies

  dep ensure -add github.com/pkg/errors  add a dependency to the project

Use "dep help [command]" for more information about a command.

获取依赖策略

获取最新TAG的依赖包

dep ensure -add github.com/gin-gonic/gin
获取指定分支的依赖包

dep ensure -add github.com/gin-gonic/gin@master
获取指定TAG的依赖包

dep ensure -add github.com/gin-gonic/gin@V1.2
获取指定TAG以上的依赖包

dep ensure -add github.com/gin-gonic/gin@^V1.2
获取依赖包的子包

dep ensure -add github.com/prometheus/client_golang/prometheus/push
获取两个子包的情况

dep ensure -add github.com/prometheus/client_golang/prometheus/push github.com/prometheus/client_golang/prometheus/promhttp
获取过程：根据命令先判断本地是否有缓存(缓存地址：$GOPATH/src/dep),存在则直接使用缓存，不存在则，先获取 git 版本/分支/tag 根据命令找到对应的版本下载。

FQAs

当拉取过程中如果出现 timeout 则请自备梯子.
当拉取出现未知的错误，可以先手动删除缓存在尝试一次
当出现 *build.NoGoError 错误，可能是 build 时当前依赖包并没有 main 函数，这种情况一般是需要拉取依赖包的子包
当已存在的项目 dep init 会遍历当前项目的依赖包，并下载，所以时间会很久

转自

https://studygolang.com/articles/13990/comment/18351

巴特西

golang的包管理---vendor/dep等