Go语言版本控制及包依赖管理

传统Go构建以及包依赖管理

  • Go在构建设计方面深受Google内部开发实践的影响,比如go get的设计就深受 Google内部单一代码仓库(single monorepo)和基于主干(trunk/mainline based)的开发模型 的影响:只获取Trunk/mainline代码和版本无感知
Go语言版本控制及包依赖管理_第1张图片
image.png
  • 我们知道go get获取的代码会放在GOROOT/src下面,而go build会在GOROOT/src和GOPATH/src下面按照import path去搜索package,由于go get 获取的都是各个package repo的trunk/mainline的代码,因此,Go 1.5之前的Go compiler都是基于目标Go程序依赖包的trunk/mainline代码去编译的。这样的机制带来的问题是显而易见的,至少包括:
  1. 因依赖包的trunk的变化,导致不同人获取和编译你的包/程序时得到的结果实质是不同的,即不能实现reproduceable build
  2. 因依赖包的trunk的变化,引入不兼容的实现,导致你的包/程序无法通过编译
  3. 因依赖包演进而无法通过编译,导致你的包/程序无法通过编译
  • 为了实现reporduceable build,Go 1.5引入了Vendor机制,Go编译器会优先在vendor下搜索依赖的第三方包,这样如果开发者将特定版本的依赖包存放在vendor下面并提交到code repo,那么所有人理论上都会得到同样的编译结果,从而实现reporduceable build

Go语言版本控制

  • 在没有版本控制时,go get 的一个重大缺陷是对于给定的更新无法知道是否是用户所期望的。

  • Go 将在下个版本(1.11)中看到官方的包版本控制,去除了 GOPATH 依赖,同时还引入了 module(模块) 的概念。

  • 版本控制可以让我们能够实现重编译。当我让你试用我程序最新版本时,我清楚的知道你不仅仅获取到的是我最新程序的代码,还包括我代码所依赖的相同版本的包,这样才能编译出完全一样的二进制包。

  • 版本控制还能让我们不同阶段保持同样的编译方式,即使我们的依赖包可能有新版本了,只要我们的配置未允许使用,go 命令也不会使用新版本的包。

  • 尽管添加版本控制是必须的功能,但同时也不能失去go 命令行现有的优秀特性:简单、高效、易懂,所以它应该足够透明不能破坏掉go get 本身功能。

  • Go新版本中保留了go get的精华部分,增加了重复构建,采用了语义化的版本控制,弃用了 vendor,废弃了基础工程创建时依赖GOPATH,并且提供了老项目平滑迁移的方式。

Go添加版本控制共分四个步骤

导入兼容规则

  • 包管理系统中最大的痛苦在于解决兼容性问题

    比如,大多数系统中包B 声明需要的包D 版本是6或者更高版本,然后包C声明所需的包D 版本是2,3和4,但不能高于版本5。如果你正在编写包A ,你想同时引入包B 和C ,那么你不走运了:没有一个独立的D 版本可以供B 和C 同时选择编译进A。B 和C 做的都是合理的,你也没办法改变它,所以你就被卡住了。

  • 为了避免主导者设计一个导致现有的大型程序无法编译的系统,提案要求包作者遵循以下导入兼容性原则:

    如果一个旧包和新包有相同的导入路径,新包必须向后兼容旧包 这条规则是对前面 Go FAQ 的重申,引用 FAQ 中最后讲的:“如果需要完全变更,那么就创建个新导入路径的包”。开发者希望能通过语义化的版本来表达这样一个变更,因此我们把语义化版本控制也加入到我们提案中。具体点说,主版本2 和更新的版本可以通过在路径中包含版本信息来区分,比如:


import "github.com/go-yaml/yaml/v2"

  • 包作者遵循导入兼容性原则可以让我们减少适配工作,让系统更简单的同时也让包生态减少碎片化
    当然,实际上尽管作者尽最大努力去做了,更新时也难免会出现破坏用户使用的情况。因此,使用一个不频繁升级的升级机制很重要,这也是接下来我们要讲的。

最小版本规则

  • 几乎现在所有的包管理包括dep和cargo都在构建时使用最新的包版本,基于两方面的重要因素,被认为这是个错误的约定:

    首先,“最新可用版本”有可能因为外部事件导致变更,像新版本发布。也许今晚你依赖的包中有人会发布个新版本,第二天早上你再编译有可能就产生不同的结果了;

    第二,为了覆盖这个默认约定,开发者花费大量的时间告诉包管理器不使用哪个版本的包。

  • 提案中我们使用了不同的方式,称之为最小版本选择。

    构建时每个包默认使用的是最老的可用版本,这个方式让昨天和今天的编译不会有变化,因为你总不会在今天发布一个更老版本吧。更好的是,开发者只需告诉包管理器最小可用的那个版本,包管理器就可以很快的决定哪个版本可用。我们称它为最小版本选择一方面是因为我们选择的是最小版本,另一方面是因为对整个系统来说是最小化的,避免了现有系统的复杂性。

    最小版本选择为模块指定了其依赖模块的最低版本需求,这为后续升级和降级操作提供了一个很好的选择。同时,它还可以通过排除指定版本的依赖或者指定特殊版本依赖完成编译。

    最小版本选择在不锁定文件情况下默认就完成了可重复构建。

    最小版本选择是导入兼容的关键。用户不会再说:“不,版本太新了”,更多情况是面临“不,版本太旧了”,这种情况下解决方案很明确:升级新版本就可以了。

Go Module

  • Go Module是共享一个导入路径前缀的包集合,也就是我们所说的模块路径

    Module是版本控制的单元,Module的版本通过语义化的版本字符串表示,当开发中使用Git 时,开发者通过给模块的Git 资源库添加一个新tag的方式来定义一个新的语义化版本。尽管强烈推荐使用语义化版本的方式,但也支持指向特定commit。

  • 模块定义在一个叫go.mod的新文件里,里面包含了模块所依赖包的最小版本

    下面就是个简单的go.mod文件:


module "rsc.io/hello"

require (

"golang.org/x/text" v0.0.0-20180208041248-4e4a3210bb54

"rsc.io/quote" v1.5.2

)

这个文件通过路径标识 rsc.io/hello 定义了一个模块,它本身还依赖于两个其他模块:golang.org/x/text 和 rsc.io/quote ,这个模块自身编译的时候使用的是 go.mod 文件中指定的依赖列表的版本。对于更上一层的编译,其他导入这个模块的地方将使用它较新的版本编译。

包发布者最好使用语义化的 tag 发布版本,vgo 也鼓励通过打tag的版本号方式,而不是任意的提交版本。

  • 除了指定必须的依赖版本,go.mod 文件还可以实现前面章节中提到的排除和替换的版本,但是这些只有当直接编译该模块的时候起作用,在模块作为整体工程一部分编译时就不行了

  • Goinstall 和旧的 go get 通过像git 和hg 这样的版本控制工具直接下载代码,这种方式存在很多问题,其中包括碎片化严重:用户如果没有bzr 就没法下载托管在Bazaar 资源库的代码。相比之下,Go Module则是通过HTTP 下载zip 包的方式。

  • Module统一通过zip包的形式提供可以让下载协议更简单,公司或者个人可以处于任何原因考虑(安全或者想要缓存副本防止源被删除)自己做下载代理,使用代理来确保可用性并且通过go.mod定义了哪些代码需要用到

Go 命令

  • go 命令必须更新才能使用模块功能。一个重要的变化就是常用的构建命令,像 gobuild, go install, go run, 和 go test 将需要按指定需求解析对应的依赖关系了

  • 最重要的变化还是终结了GOPATH作为Go 代码工作空间的设置,由于go.mod文件包含了完整的模块路径并且还定义了每个使用的依赖的版本,因此包含go.mod文件的目录就可以被认为是一个目录树的根目录了,该目录树作用于自身的工作空间,并且和其他类似的目录彼此隔离。现在你只需git clone然后cd就可以直接撸代码了,不再需要GOPATH了

你可能感兴趣的:(Go语言版本控制及包依赖管理)