微信号:infoqchina

介绍:有内容的技术社区媒体

寻找最优解,Golang的包管理之道

2016-02-22 08:01 肖德时

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。所以,你复制的那一份代码已经开始工作后,谁还敢动呢?更糟糕的是,如果这个第三方库的开发者很活跃,代码更新更快,如何升级我们的引用代码呢?

  • 官方的办法对于普通的程序问题不是很大,最多就是编译时的依赖。但如果你写的是一个给其他人使用的类库,引入这个库就会带来麻烦了。你这个库被多人引用,如何管理你这个库的代码依赖呢?难道还是一股脑的复制吗?

几种解法与其利弊

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

  • 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 的配置文件例子参考:


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

给一个例子参考:


未来

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原创首发,未经授权谢绝转载。

InfoQ原创翻译编辑&技术编辑招募中,简历快砸来:editors@cn.infoq.com

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 独家放送|金融IT行业与容器的巅峰对话:听睿云智合CTO徐年刚畅谈金融行业基于容器技术的DevOps 测试是浪费时间,我的程序肯定没问题 如果编程语言是种武器 就因为刷了刷新闻,他被上市公司大佬请喝茶... 学习R语言,一篇文章让你从懵圈到入门