go vendor的用法

使用go很长时间后才整明白vendor的用法为啥这么坑人。

1. 通常目录结构：

$GOPATH/src
  |----appmodule1
        |----*.go
  |----appmodule2
        |----*.go
  |----<main>
       |----main.go
       |----vendor
             |----github.com

注意

1. 模块<main>指得是你的app的main模块名字，当然也可以使用appname作为目录名，但是这里面的文件例如main.go必须用main作用package name，因为这个模块是应该main模块的；(相比较其他的appmodule1，appmodule2，他们的模块名也应该是路径名)
2. vender必须在模块目录下面，例如main/vendor，而不能在GOPATH/src目录下面。

2. go编译办法

这和当前工作路径相关：

1. 如果当前路径在$GOPATH/src，或者其子目录下面，那么vendor有效。
   • PWD=$GOPATH/src/main: go build
   • PWD=$GOPATH/src: go build -o <myapp> main/main.go
2. 如果当前路径不在$GOPATH/src，或者其子目录下面，那么vendor无效，因为使用的是module依赖，而不是vendor依赖包管理了。

GOPATH的历史

1. go最早的时候只支持GOPATH
2. go1.5引入通知设置GO15VENDOREXPERIMENT=1开始支持vendor，注意还是需要GOPATH
3. go1.11引入module概念，同时引入GO111MODULE=auto|on|off，至此可以不需要GOPATH

• GO111MODULE=on，使用go module，不使用GOPATH
• GO111MODULE=off，使用GOPATH，不使用go module
• GO111MODULE=auto，取决于当前工作路径
  • 如果在GOPATH/src内，等同于GO111MODULE=off，即使用GOPATH
  • 如果在GOPATH/src外，等同于GO111MODULE=on，即不是GOPATH

总结go module和vendor

go module和vendor是两个冲突的设计，二者只能选一，不可混用。

1. vendor依赖的是GOPATH，那么必须设置GOPATH
2. module不使用GOPATH，那么不能设置GOPATH

如果从vendor到module迁移的怎么办：
-mod=vendor