go - 在 Go 中处理依赖关系

Question

在 Go 中，如果您引用另一个包，例如GitHub 上的一些东西，然后 Go 总是从 master 分支获取最新版本。虽然这对开发很有帮助，但我想这是生产中的一个问题:这样构建就无法重现。

那么，在 Go 中修复依赖版本的正确方法是什么，以及如何有效地处理这个问题？

一位 friend 向我指出了 godep ，这看起来不错，但我想知道有哪些替代方案，以及 godep 的优点/缺点是什么？

Answer 1

使用 Go 1.11 更新 2018

Dependencies should now be referenced with modules (源自 the vgo project ):

Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution.
Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible.

参见 Defining a module 。 (和 original design proposal )

---

2015 年 6 月更新:Go 1.5 首次支持 vendoring!
参见 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.

---

2015 年 3 月更新:go 团队正在考虑定义一个集成到语言中的 go 依赖管理系统:争论是 in this thread .

We think it’s time to start addressing the dependency & vendoring issue, especially before too many conflicting tools arise and fragment best practices in the Go ecosystem, unnecessarily complicating tooling. It would be nice if the community could converge on a standard way to vendor.

Our proposal is that the Go project,

1. officially recommends vendoring into an “internal” directory with import rewriting (not GOPATH modifications) as the canonical way to pin dependencies.
2. defines a common config file format for dependencies & vendoring
3. makes no code changes to cmd/go in Go 1.5. External tools such as “godep” or “nut” will implement 1) and 2). We can reevaluate including such a tool in Go 1.6+.

---

godep 的一个可能缺点是你不能再直接使用“go build”或“go test”。
您需要在这些命令之前加上 godep(或键入 godep save)。

另一种选择是 glide ，它仍然与经典的 go 命令兼容。

• Manage project-specific GOPATHs
• Ease dependency management
• Support versioning packages
• Support aliasing packages (e.g. for working with github forks)
• Remove the need for "vendoring" or munging import statements
• Work with all of the go tools

---

更一般地说，文章“Know your guarantees, Go edition”很有趣:

It’s also a deliberate choice, where the Go authors chose not to implement a feature when they felt that the trade-offs were no good.

One low-level reason they made this choice is to avoid slow compilation and bloated binaries (which are two sides of the same coin).
Remember, packages depend on other packages. So Foo might depend on Bar 2.1. Foo might also depend on Baz which in turn depends on Bar 1.9, and on down the tree. So that would mean compiling and linking several copies of nearly identical code.

Depending on several versions of the same package also means knowing which version one is calling, whereby the dependency mess seeps into your source code.

Which leads us to the high-level reasoning behind the Go platform punting on this feature: they did not have a logical solution they considered acceptable. It’s not that they don’t understand the problem; it’s that, at the moment, there is not a solution they like. So they choose no feature over over a regressive one.