Golang 依赖管理最佳实践 [英] Golang Dependency Management Best Practice

问题描述

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

In Golang, we can specify open source libraries on GitHub as dependencies. For example:

import "github.com/RichardKnop/somelibrary"

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

This will try to look for a branch based on your Go version and default to master if I understand correctly.

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

So there is no way to import a specific release of a dependency, e.g.:

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

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

What is the best practise to manage dependencies in Go then?

我可以看到两种方法.

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

Is it to create new modules for major versions with breaking changes?

例如，我的 Go 库可以定义模块 v1 和 v2，所以你可以这样做:

For example, my Go library could define modules v1 and v2 so then you could do:

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

或者:

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

根据您的需要.对 v1 或 v2 所做的任何更改都必须不破坏任何 API 或工作功能.

Based on what you need. Any changes made to v1 or v2 would be required not to break any APIs or working functionality.

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

This would give you a complete control over a version of external dependency your Go code requires.

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

For example, you could fork github.com/RichardKnop/somelibrary into your own GitHub account and then in your code do:

import "github.com/ForkingUser/somelibrary"

然后你将不得不分叉所有外部依赖，这似乎有点过分.但是，它可以让您完全控制版本.您可以将 fork 保留在您知道可以与您的代码一起使用的版本上，并且仅在您检查新版本的依赖项不会破坏任何内容后才更新 fork.

Then you would have to fork all external dependencies which seems a bit overkill. However it would give you total control over versions. You could keep your forks at a version you know is working with your code and only update forks once you have checked that new releases of dependencies do not break anything.

想法?

推荐答案

注意:2015 年 6 月，Go 1.5 中首次支持 vendoring！

Note: June 2015, the first support for vendoring appears in Go 1.5!

参见 c/10923/:

当 GO15VENDOREXPERIMENT=1 在环境中时，此 CL 根据 Go 1.5 供应商建议更改导入路径的分辨率:

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

• 如果有一个源目录d/vendor，那么在以d为根的子树中编译源文件时，import "p" 被解释为 import "d/vendor/p" 如果存在.
• 当有多种可能的解决方案时，最具体(最长)的路径获胜.
• 必须始终使用简短格式:任何导入路径都不能明确包含/vendor/".
• 在供应商包中忽略导入注释.

• 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 将使 vendoring 成为默认值.
正如文章现在最适合使用的工具GO15供应商实验":

1.6 为大多数工具(如 oracle)提供了开箱即用的对 /vendor/ 的支持；使用 Beta 版重建它们.

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

• 问题 12278 已解决.
• goimports 仍然存在问题a>，并且有一个 CL 可以挑选.
• issue 12278 has been resolved.
• there still is an issue with goimports, and there is a CL that can be cherry-picked.

这篇关于Golang 依赖管理最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！