一尘不染

Golang依赖性管理最佳实践

go

在Golang中,我们可以将GitHub上的开源库指定为依赖项。例如:

import "github.com/RichardKnop/somelibrary"

如果我理解正确,这将尝试根据您的Go版本查找分支,默认为master。

因此,无法导入依赖的特定版本,例如:

import "github.com/RichardKnop/somelibrary#v1.4.8"

那么,在Go中管理依赖项的最佳实践是什么?

我可以看到两种方法。

I.版本模块

是否为具有重大变更的主要版本创建新模块?

例如,我的Go库可以定义模块v1和v2,因此您可以执行以下操作:

import "github.com/RichardKnop/somelibrary/v1"

要么:

import "github.com/RichardKnop/somelibrary/v2"

根据您的需要。必须对v1或v2进行任何更改,以免破坏任何API或正常工作的功能。

二。分叉

这样可以完全控制Go代码所需的外部依赖版本。

例如,您可以将github.com/RichardKnop/somelibrary分支到您自己的GitHub帐户中,然后在您的代码中执行以下操作:

import "github.com/ForkingUser/somelibrary"

然后,您将不得不分叉所有外部依赖项,这似乎有些过大。但是,它将完全控制版本。您可以将fork保持在您正在使用代码的版本上,并且仅在检查新版本的依赖项不会破坏任何内容后才更新fork。

有什么想法吗?


阅读 351

收藏
2020-07-02

共1个答案

一尘不染

注意:2015年6月,Go 1.5中首次提供了对卖家的支持!

参见c / 10923 /

GO15VENDOREXPERIMENT=1在环境中,这种CL变化的根据围棋1.5供应商建议的进口路径的分辨率:

  • 如果存在源目录d/vendor,则在以开头的子树中编译源文件时dimport "p"将其解释为import "d/vendor/p"存在。
  • 如果有多种可能的解决方案,则以最具体(最长)的路径为准。
  • 必须始终使用简写形式:任何导入路径都不能/vendor/明确包含“ ”。
  • 供应商软件包中的导入注释将被忽略。

2016年1月更新:Go 1.6将使供应商成为默认供应商。
文章“使用GO15VENDOREXPERIMENT现在可以使用更便宜的工具”中所述

1.6提供了/vendor/对大多数工具(例如oracle)的支持;使用Beta来重建它们。

2020-07-02