BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

Golang的包管理之道

| 作者 肖德时 关注 2 他的粉丝 发布于 2016年2月14日. 估计阅读时间: 2 分钟 | 硅谷人工智能、机器学习、互联网金融、未来移动技术架构 ,尽在QCon上海2017

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

Go包管理的现状和问题

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

  1. 网络环境是一个瓶颈,尤其是遇到大量的依赖包下载时,下载过程就是让开发者长时间等待的过程,直至无法忍受。此类问题困扰多了,国内的开发者做了一个异步下载 Golang 包的镜像服务来尝试解决它。但在日常工作中,这种间接的办法并不能有效的解决此类问题。
  2. Golang 的第三方包是没有中央库统一管理的,所以不存在索引库的概念。遇到需要的库,一定要小心的检查包的可用性。因为包管理并没有全局的版本控制。当你在本地编译成功之后分享给同事时并不能保障你的同事就能一次编译成功。类库版本不对的情况时常发生,以至于开发者不得不把依赖包直接加到应用代码仓库中。类库小的几十兆,大的上百兆,从开发者的角度来说,代码干净程度是决定一个程序是否优雅和品位的,但是加入例如几百兆的依赖包实在是无奈之举,此方法并没解决问题。实际上理想中的包管理设计应该是可以自动应对包的依赖管理的,例如 python 的 pip,ruby 的 Bundler。
  3. 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 命令,仍然过于简单。对于现实过程中的开发者来说,仍然有其痛苦的地方。

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

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

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

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

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

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

几种解法,利弊

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

到了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 强调的是代码的干净度胜过代码的重用。这是不一样的编程哲学,还请大家且行且珍惜。

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

  • 当你开源类库时,请尽量的少用第三方库,学会使用标准库。发布的类库,也请使用版本服务,类如gopkg.in来管理版本。
  • 对于程序的包管理,使用官方推荐的工具来管理。如果你有自己的想法,请直接对这些官方推荐的工具做贡献,让社区一起来共同解决这个问题。

作者

肖德时,北京数人科技有限公司CTO,负责云计算的研发及架构设计工作。关注领域包括Docker,Mesos集群, 云计算等领域。 肖德时之前为红帽Engineering Service部门内部工具组Team Leader。

参考


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

so-you-want-to-write-a-package-manager by Liu Treri

Re: so-you-want-to-write-a-package-manager by Guo Gary

有兴趣翻译下这篇文章吗?

ayanamist by Yang Ayanamist

Google内部对CPP项目的依赖管理就是把代码全部ci的,所以golang继承了这个习惯

Re: so-you-want-to-write-a-package-manager by Liu Treri

我也是无意看到这篇文章的
看懂可以, 但是翻译的话, 对我来说体量可能有些大

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT