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

问题描述

在Golang中，我们可以在GitHub上指定开源库作为依赖关系。例如：

  importgithub.com/RichardKnop/somelibrary
  

如果我理解正确，这将尝试寻找基于Go版本的分支，并且默认为master。

因此，没有办法导入特定版本的依赖项，例如：

  importgithub.com/RichardKnop /somelibrary#v1.4.8
  

在Go中管理依赖关系的最佳实践是什么？

我可以看到两种方法。

I。版本模块

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

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

  importgithub.com/RichardKnop/somelibrary/v1
  

或者：

  importgithub.com/RichardKnop/somelibrary/v2
  

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

II。分叉

这会让您完全控制Go代码所需的外部依赖版本。

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

  import github.com/ForkingUser/somelibrary
  

然后，你将不得不分叉所有的外部依赖，这似乎有点矫枉过正。但它会让你完全控制版本。您可以将您的叉子保留在您认为正在处理您的代码的版本中，并且只有在您检查到新版本的依赖关系不会破坏任何内容后才更新叉子。

想法？

解决方案

注意：2015年6月，首次支持vendoring出现在Go 1.5中！

请参阅 c / 10923 / ：

当环境中存在 GO15VENDOREXPERIMENT = 1 时，此CL会根据以下条件更改导入路径的分辨率： Go 1.5供应商建议：

$ ul

如果源目录 d / vendor ，那么当在以 d 为根的子树内编译源文件时， importp被解释为<$如果存在，c $ c>导入d / vendor / p。

当存在多种可能的分辨率时，最具体（最长）的路径获胜。

必须始终使用简写形式：没有导入路径可以明确包含 / vendor / 。

---

2016年1月更新：Go 1.6将使默认销售成为可能。

详情请参阅

blockquote>
<1.6>为大多数工具（如oracle）提供了对 / vendor / 的支持;使用Beta重建它们。

• issue 12278 已解决。
问题出在 goimports 上，并有一个 CL 可以选樱桃 。

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

import "github.com/RichardKnop/somelibrary"

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"

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

I can see two approaches.

I. Version Modules

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

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

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

Or:

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

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

II. Forking

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

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"

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.

Thoughts?

解决方案

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

See 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.

---

Update January 2016: Go 1.6 will make vendoring the default.
And as detailed in 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 has been resolved.
• there still is an issue with goimports, and there is a CL that can be cherry-picked.

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