Go包管理--godep
关于Godep
golang设计者最初过于乐观的设计使得今天大 家不得不各自想办法解决这个问题。godep就是综合了多年第三方包依赖问题的解决方案后的一个趋向统一的方案，至少是在go get的设计没有进化前的一个比较不错的方案。发现好多golang项目都使用到godep作为包管理的工具，像比较大型的项目，比如kubernetes这种，都是使用的是godep来进行依赖管理操作的了，看了一下有点像maven的感觉。
安装：
https://github.com/tools/godep
go get github.com/tools/godep成功安装后，在$GOPATH的bin目录下会有一个godep可执行的二进制文件，后面执行的命令都是用这个，建议这个目录加入到全局环境变量中
编译和运行
项目用godep管理后，要编译和运行项目的时候再用go run和go build显然就不行了，因为go命令是直接到GOPATH目录下去找第三方库。 而使用godep下载的依赖库放到Godeps/workspace目录下的；
godep go run main.go
godep go build
godep go install
godep go testgodep中的go命令，就是将原先的go命令加了一层壳，执行godep go的时候，会将当前项目的workspace目录加入GOPATH变量中；
godep save 检出依赖
godep save将项目中使用到的第三方库复制到项目的Godeps目录下。
godep save 会自动扫描当前目录所属包中import的所有外部依赖库（非系统库），并查看其是否属于某个代码管理工具（比如git，hg）。若是，则把此库获取路径和当前对应的revision（commit id）记录到当前目录Godeps下的Godeps.json，同时，把不含代码管理信息（如.git目录）的代码拷贝到Godeps/_workspace/src下，用于后继godep go build等命令执行时固定查找依赖包的路径。
因此，godep save能否成功执行需要有两个要素： 当前或者需扫描的包均能够编译成功：因此所有依赖包事先都应该已经或go get或手工操作保存到当前GOPATH路径下 依赖包必须使用了某个代码管理工具（如git，hg）：这是因为godep需要记录revision
godep restore
如果下载的项目中只有Godeps.json文件，而没有包含第三库则可以使用godep restore这个命令将所有的依赖库下来下来到GOPATH的src中。
godep restoregodep restore执行时，godep会按照Godeps/Godeps.json内列表，依次执行go get -d -v 来下载对应依赖包到GOPATH路径下，因此，如果某个原先的依赖包保存路径（GOPATH下的相对路径）与下载url路径不一致，比如kuberbetes在github上路径是github.com/kubernetes，而代码内import则是k8s.io，则会导致无法下载成功，也就是说godep restore不成功。这种只能手动，比如手动创建$GOPATH/k8s.io目录，然后git clone。
golang自带包管理工具
自带工具：go get go get可以将依赖的第三方库下载本GOPATH目录，在代码中直接import相应的代码库就可以了。 与godep相比，如果项目引用的第三方库没有列入到项目里面，安装项目时，针对第三方库需要使用go get一个个下载，比较麻烦；
注：使用godep restore可能导致部分库无法下载下来；编译会报错： cmd/decode.go:16:2: cannot find package "github.com/CodisLabs/redis-port/pkg/libs/atomic2" in any of:
此时针对报错的特定库再go get一般都能下载： go get github.com/CodisLabs/redis-port/pkg/libs/atomic2
godep支持的命令
save list and copy dependencies into Godeps
go run the go tool with saved dependencies
get download and install packages with specified dependencies
path print GOPATH for dependency code
restore check out listed dependency versions in GOPATH
update update selected packages or the go version
diff shows the diff between current and previously saved set of dependencies
version show version info笔记
1.执行godep save,此时会生成Godeps文件夹，同时将引用的放入vendor文件夹中。
例子(老版本)
按照godep官方使用说明的第一步，先下载godep：
$ go get github.com/tools/godep
$ godep
Godep is a tool for managing Go package dependencies.
Usage:
godep command [arguments]
The commands are:
save list and copy dependencies into Godeps
go run the go tool in a sandbox
get download and install packages with specified dependencies
path print sandbox path for use in a GOPATH
restore check out listed dependency versions in GOPATH
update use different revision of selected packages
Use "godep help [command]" for more information about a command.确认正确下载后，我们来准备一个测试例子，目录如下：
$GOPATH/
src/
tonybai.com/
foolib/
foo.go
fooapp/
main.go
//foo.go
package foo
func Add(a, b int) int {
return a + b
}
//main.go
package main
import (
"fmt"
foo "tonybai.com/foolib"
)
func main() {
fmt.Println(foo.Add(1, 3))
}
在fooapp下，编译执行程序：
$go run main.go
4接下来godep登场，根据godep文档中得步骤，接下来我们应该在一个构建依赖关系完整的项目中执行godep save以保存依赖关系以及依赖的当前版本第三方包：
$godep save
godep: directory "/Users/tony/Test/GoToolsProjects/src" is not using a known version control system
godep: error loading dependencies出错了！godep提示$GOPATH/src目录没有使用任何版本控制系统(not using a known version control system)。 奇怪啊！这个错误什么意思呢？难道使用godep还需要将$GOPATH/src整体作为一个Project纳入git or subversion repository中？无奈之下，我只能先这么做，再作观察。我在$GOPATH下执行git init，建立一个local git repository，然后将src add到这个repository中。
回到fooapp下，再次执行godep save，居然依旧是同样地错误结果。于是到godep的issues中去查，看看是否有人和我遇到了同样地问题！godep的#116 issue中提到的问题恰恰和我的一致，不过这个issue一 直是open状态，也没有人comments。接着翻看一下godep的源码，godep依赖一些第三方包，save这个命令在分析版本控制工具库时也是 调用了多层外部包实现的，短时间内无法定位问题
静想一下，godep是管理第三方包依赖关系的，而第三方包多是go get下载的，是不是foolib要放到repository中才行呢？于是尝试在foolib中建立git repository并做一次commit。第三次在fooapp下执行godep save，错误依旧！
难道fooapp也必须放在repository中？试试吧。在fooapp下init一个git repository，将fooapp下的main.go提交到repository中。再执行godep save：
$godep save
$ls -l
total 8
drwxr-xr-x 5 tony staff 170 10 30 22:01 Godeps/
-rw-r–r– 1 tony staff 103 10 30 21:44 main.go这回成功了！godep save在fooapp下建立了Godeps目录，其结构如下：
$ls -R
Godeps.json Readme _workspace/
./_workspace:
src/
./_workspace/src:
tonybai.com/
./_workspace/src/tonybai.com:
foolib/
./_workspace/src/tonybai.com/foolib:
foolib.gogodep将当前版本的foolib copy到Godeps/_workspace下了。
Godeps.json记录了fooapp对foolib的依赖关系：
{
"ImportPath": "fooapp",
"GoVersion": "go1.3",
"Deps": [
{
"ImportPath": "tonybai.com/foolib",
"Rev": "20a9c2a682537813d37847f2f270bf929672cc84"
}
]
}godep记录了foolib的当前revision number，这个number恰是我最新一次commit的hash code。
到这里让我觉得godep的设计思路有些与我的buildc（C程序辅助构建工具）的思路有些类似，只是godep做得更彻底：
1、godep将项目依赖统统放到项目的私有_workspace下，而buildc是共享的，通过project下的版本号配置区分依赖
2、godep将依赖管理到revision(修订号)级别，buildc只是根据version来区分依赖。
godep的辅助构建原理（godep go build main.go）通过一条命令即可看出来：
$godep go env
GOARCH="amd64"
GOBIN="/usr/local/go/bin"
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tony/Test/GoToolsProjects/src/fooapp/Godeps/_workspace:/Users/tony/Test/GoToolsProjects"godep临时将_workspace放在GOPATH列表的前面，这样gc在编译时就会按顺序先在_workspace下面找依赖包，这样fooapp的私有依赖就会理所当然的被gc用到，即便在其他GOPATH路径下有同名包（可能是不同版本的）。
显然这也算是godep的一个小bug吧（或者是godep依赖的包的bug，目前不确认），毕竟提示的路径是不正确的，不应该提示"/Users/tony/Test/GoToolsProjects/src" is not using a known version control system，而应该是"/Users/tony/Test/GoToolsProjects/src/tonybai.com/foolib或"/Users/tony/Test/GoToolsProjects/src/fooapp没有版本控制系统的repository留存。
参考:
https://tonybai.com/2014/10/30/a-hole-of-godep/
https://www.cnblogs.com/zuxingyu/p/6015715.html
End