转载

Golang的包管理之道

对于一门编程语言的开发者，类库包管理是一项考核编程语言成熟度的重要指标之一，Golang 也不例外。笔者在日常使用Golang语言开发系统程序时发现，在 Golang 的世界里，存在着大量的技术实现讨论和各种自制的解决方案。因为Golang官方并没有推荐最佳的包管理方案，开发者在选择心目中最优的包管理方案时总会耗费精力去选择合适自己的方案。所以本文的目的就是想和大家一起，针对Golang 包管理的设计问题，一起探讨Golang包管理问题出现的原因以及解决办法，在详细的对比探讨之后，间接地体会出Golang语言的开发团队对语言设计的深层设计哲学。

Golang的包管理之道

Go包管理的现状和问题

目前主流的编程语言 Python、Ruby、Java、Php 等已经把包管理的流程设计的犹如行云流水般流畅，一般情况下开发者是不需要操心类库包依赖管理以及升级、备份、团队协作的。在 Golang 的世界里，尤其是在1.5之前，此类库包管理的流程设计真的是“仅仅”能工作的状态。笔者结合日常开发过程中遇到的问题，整理出 Golang 语言包管理的现状如下：

网络环境是一个瓶颈，尤其是遇到大量的依赖包下载时，下载过程就是让开发者长时间等待的过程，直至无法忍受。此类问题困扰多了，国内的开发者做了一个异步下载 Golang 包的镜像服务来尝试解决它。但在日常工作中，这种间接的办法并不能有效的解决此类问题。
Golang 的第三方包是没有中央库统一管理的，所以不存在索引库的概念。遇到需要的库，一定要小心的检查包的可用性。因为包管理并没有全局的版本控制。当你在本地编译成功之后分享给同事时并不能保障你的同事就能一次编译成功。类库版本不对的情况时常发生，以至于开发者不得不把依赖包直接加到应用代码仓库中。类库小的几十兆，大的上百兆，从开发者的角度来说，代码干净程度是决定一个程序是否优雅和品位的，但是加入例如几百兆的依赖包实在是无奈之举，此方法并没解决问题。实际上理想中的包管理设计应该是可以自动应对包的依赖管理的，例如 python 的 pip，ruby 的 Bundler。
Golang 作为云计算时代最流行的系统级编程语言，目前在全球开发者社区都受到热烈的关注和大量的使用。业界不乏开发者推出自己的包管理解决办法，混乱的包管理治理工作对于开发者来说，耗费了大量的精力。Golang 的开发组也是迟迟没有给出统一的解决办法。

当然，目前 Golang 到了1.5版本时代，官方开始引入包管理的设计，加了 vendor目录来支持本地包管理依赖。这个方法目前还不是默认开放的，goimports 并不能直接使用。官方会在1.6版本开始正式启用这个特性。为了在1.5环境下启用这个特性，Golang 启用了一个环境变量作为开关： GO15VENDOREXPERIMENT=1 ，1.6之后就会默认启用不再使用此环境变量。

原因分析

笔者认为，Golang 语言的设计者都是多年经验的世界级语言开发者，发明它也是为了谷歌内部替代 C++/C 的系统级语言，不可能没有考虑包管理。所以 Golang 对包管理一定有自己的理解。笔者从一开始接触Golang 时就发现，它真的引入的新的语言概念非常少。对于包的获取，就是用 go get命令从远程代码库(GitHub, Bitbucket, Google Code, Launchpad)拉取。这样做的好处是，直接跳过了包管理中央库的的约束，让代码的拉取直接基于版本控制库，大家的协作管理都是基于这个版本依赖库来互动。细体会下，发现这种设计的好处是去掉冗余，直接复用最基本的代码基础设施。Golang 这么干很大程度上减轻了开发者对包管理的复杂概念的理解负担，设计的很巧妙。

当然，go tools 引入的 go get 命令，仍然过于简单。对于现实过程中的开发者来说，仍然有其痛苦的地方。

缺乏明确显示的版本。团队开发容易导入不一样的版本
第三方包没有内容安全审计，很容易引入代码 Bug
依赖的完整性无法校验，程序编译时无法保障百分百成功

Go开发组对于此类问题的建议是把外部依赖的代码复制到你的源码库中管理。

包管理的问题，并不是一个单点问题。它涉及到程序的工程操作性。开发者需要的是可以在任何时间，任何地点和环境，可以反复的编译出同样的程序： ReproducibleBuild

可以在特定的分支上重现一个 Bug
使用 bisect 可以隔离出哪一次提交引入的 Bug

所以，官方推荐把第三方代码引入自己的代码库仍然是一种折中的办法：

对于之前的 go get。我们如何升级依赖库的版本。仍然需要第三方工具或者脚本来维护类库，本身就是有点复杂。
我们很难直接针对第三方库的 Bug，贡献代码修复 Bug。所以，你复制的那一份代码已经开始工作后，谁还敢动呢？更糟糕的是，如果这个第三方库的开发者很活跃，代码更新更快，如何升级我们的引用代码呢？
官方的办法对于普通的程序问题不是很大，最多就是编译时的依赖。但如果你写的是一个给其他人使用的类库，引入这个库就会带来麻烦了。你这个库被多人引用，如何管理你这个库的代码依赖呢？难道还是一股脑的复制吗？

几种解法，利弊

由于官方对于包管理暂时没有明确的指导意见，所以，作为社区驱动的一门语言，不缺乏各路优秀开发者推出的自己的最佳实践工具：

https://github.com/tools/godep
https://github.com/gpmgo/gopm
https://github.com/pote/gpm
https://github.com/nitrous-io/goop
https://github.com/alouche/rodent
https://github.com/jingweno/nut
https://github.com/niemeyer/gopkg
https://github.com/mjibson/party
https://github.com/kardianos/vendor
https://github.com/kisielk/vendorize
https://github.com/mattn/gom
https://github.com/dkulchenko/bunch
https://github.com/skelterjohn/wgo
https://github.com/Masterminds/glide
https://github.com/robfig/glock
https://bitbucket.org/vegansk/gobs
https://launchpad.net/godeps
https://github.com/d2fn/gopack
https://github.com/laher/gopin
https://github.com/LyricalSecurity/gigo
https://github.com/VividCortex/johnny-deps

到了1.5后Golang的Vendor目录特性出来后，官方 Wiki 推荐了支持此特性的包管理工具如下：

Godep
Govendor
godm
vexp
gv
gvt - Recursively retrieve and vendor packages.
govend
Glide

根据笔者的实践总结下来，对于国外的开发者，因为没有“国家防火墙”的限制，带宽也会非常充足。我推荐使用的工具是 Glide，推荐原因是设计简洁，符合 Golang 的一贯风格。

给一个glide 的配置文件例子参考：

package: main                                                                                                                     import:                                                                             - package: github.com/coreos/go-etcd                                                ref:     cc90c7b091275e606ad0ca7102a23fb2072f3f5e                                 subpackages:                                                                        - etcd                                                                        - package: github.com/docker/distribution                                           ref:     9038e48c3b982f8e82281ea486f078a73731ac4e                               - package: github.com/mailgun/log                                                  ref:     44874009257d4d47ba9806f1b7f72a32a015e4d8                               - package: github.com/mailgun/oxy                                                  ref:     547c334d658398c05b346c0b79d8f47ba2e1473b                                subpackages:                                                                       - cbreaker                                                                       - forward                                                                        - memmetrics                                                                     - roundrobin                                                                     - utils                                                                       - package: github.com/hashicorp/consul                                             ref:     de080672fee9e6104572eeea89eccdca135bb918                                subpackages:

对于国内开发者来说，最好是能一个一个包来管理。遇到网络问题，可以通过国内镜像下载。在这样的情况之下gvt 就是一个不错的选择。它可以帮助我们把一个包以及依赖都彻底的拉到本地的代码库中，统一了团队协作过程中编译环境不一致的问题。

给一个例子参考：

$ gvt fetch github.com/fatih/color 2015/09/05 02:38:06 fetching recursive dependency github.com/mattn/go-isatty 2015/09/05 02:38:07 fetching recursive dependency github.com/shiena/ansicolor  $ tree -d . └── vendor     └── github.com         ├── fatih         │   └── color         ├── mattn         │   └── go-isatty         └── shiena             └── ansicolor                 └── ansicolor  9 directories  $ cat > main.go package main import "github.com/fatih/color" func main() {     color.Red("Hello, world!") }  $ export GO15VENDOREXPERIMENT=1 $ go build . $ ./hello Hello, world!  $ git add main.go vendor/ && git commit

未来

Golang 社区一直遵循“尽量简单”的原则，从不多加一份可能的设计负担给用户，这也是我喜欢它的原因。对于管理依赖的处理，是 Go开发组一直重视的技术点，它的重要性远比“DRY”原则还过之：

“Through the design of the standard library, great effort was spent on controlling dependencies. It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse.” - Go at Google

Go Team 强调的是代码的干净度胜过代码的重用。这是不一样的编程哲学，还请大家且行且珍惜。

总结下官方对包管理依赖的建议如下：