Golang依赖管理最佳实践

发布时间：2020-12-16 09:43:41 所属栏目：大数据来源：网络整理

导读：在Golang，我们可以在GitHub上指定开源库作为依赖。例如： import "github.com/RichardKnop/somelibrary" 这将尝试寻找一个分支，基于您的Go版本和默认为master如果我理解正确。所以没有办法导入一个特定版本的依赖，例如： import "github.com/RichardKnop

在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或工作功能。

II。分叉

这将使您完全控制Go代码所需的外部依赖项的版本。

例如，您可以将github.com/RichardKnop/somelibrary fork到您自己的GitHub帐户中，然后在您的代码中执行：

import "github.com/ForkingUser/somelibrary"

然后你必须fork所有外部依赖，这似乎有点凌乱。但它会给你完全控制版本。你可以保持你的分叉的版本，你知道是在使用你的代码，只有更新叉，一旦你检查了新版本的依赖关系不会破坏任何东西。

想法？

注意：2015年6月，第一个支持出现在Go 1.5！

见c/10923/：

When GO15VENDOREXPERIMENT=1 is in the environment,this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:

If there is a source directory d/vendor,then,when compiling a source file within the subtree rooted at d,import "p" is interpreted as import "d/vendor/p" if that exists.

When there are multiple possible resolutions,the most specific (longest) path wins.

The short form must always be used: no import path can contain “/vendor/” explicitly.

Import comments are ignored in vendored packages.

更新2016年1月：Go 1.6将使默认。
详细the article “MOST GO TOOLS NOW WORK WITH GO15VENDOREXPERIMENT”：

1.6 brings support for /vendor/ to most tools (like the oracle) out of the box; use the Beta to rebuild them.

> issue 12278已解决。
>还有一个issue with goimports，还有一个CL是can be cherry-picked。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!