Go 1.5中的包版本管理

Question

我正在处理Go，虽然我理解并理解所构建的简单性原则，但我想在他们的依赖抓取工具和import语句中理解放弃一个内置的包版本控制方法的理由。

如果我正确理解，go get和import从HEAD中获取包，它们无法引用分支或标记。虽然有像gopkg.in这样的工具可以绕过这一限制，但官方工具链：

1. 迫使开发人员为其产品的主要版本创建单独的repos。
2. 它不允许消费者在小版本或微版本之间降级，以防在新版本中发现bug。

说实话，事情并不是那么容易，因为包版本控制需要一种策略来处理冲突的传递依赖，例如X依赖于A和B，这两种依赖于不同版本的C。

从Java背景来看，这一限制确实带来了一些风险和问题，其中包括：

1. 第三方deps的产品/包演变和公共API的破坏是不可避免的，因此版本控制必须是工具链IMHO中的一流公民。
2. 每个版本的Git回购策略效率很低：

- The overall Git history of the package is lost or scattered across repos (merges between versions, backports, etc.) 
- Conflicts with transitive dependencies may still occur, and will go about undetected because the language nor the toolchain impose any semantics to allow detection in the first place.

​

1. 考虑到以下情况，企业采用可能会受到阻碍，开发团队可能会回避这种语言：

- Always dragging in `HEAD` means that they can't control or freeze their 3rd party deps, leading to a potentially unpredictable end product.
- May lack the manpower to keep their product constantly updated and tested with upstream's `HEAD` (not every company in the world is Google :)).

​

虽然我理解后一种风险可以--而且必须--通过持续集成来减轻，但它不能解决问题的根本根源。

我漏掉了什么信息？在人力有限的企业中部署Go时，您如何处理包上游的变化？

Answer 1

Go 1.5的一部分扶手正在处理它，它是一个实验性特性，如果go命令在其环境中与GO15VENDOREXPERIMENT=1一起运行，则可以启用它，并且它将是Go 1.6中的一个“完整”特性。也见供应商目录。

导致Go 1.5Vedor实验的最初讨论可以找到这里。

监控的本质是创建一个名为vendor的文件夹，并将代码所依赖的包的确切版本放入其中。vendor文件夹中的代码只能通过根植于vendor父目录树中的代码来导入，并且您可以使用导入路径从vendor导入包，就好像vendor将是workspace/src文件夹一样(也就是说，导入路径省略了前缀并包含供应商元素)。

示例：

/home/user/goworkspace/
    src/
        mymath/
            mymath.go
            vendor/
                github.com/somebob/math
                    math.go

在本例中，github.com/somebob/math是mymath包(来自mymath.go)使用的外部包。如果它是从mymath.go导入的，则可以使用它，如：

import "github.com/somebob/math"

(而不是import mymath/vendor/github.com/somebob/math，这将是不好的。)

Answer 2

虽然Go没有提供标准的包管理器，但是有足够的选项使构建可以复制(即使在人力有限的企业中也是如此)。

1. 在@icza的另一个答复中对此进行了描述。这几乎相当于在Java中检查版本化的jar文件。在maven流行之前，这是使用ant构建工具的非常常见的方法。实际上，推荐更好，因为您不能丢失源代码。
2. 这是第一种选择的细微变化。您可以在构建期间通过签出依赖项的预定义版本来填充供应商文件夹，而不是签入分布式源代码。有一些工具(例如滑动)可以使这一过程自动化。
3. 最后，您可以在内部存储库中维护所有第三方库的预定义版本，并将其添加到GOPATH。这种方法在https://blog.gopheracademy.com/advent-2015/go-in-a-monorepo/中有详细的描述。

注意，不兼容的传递依赖项并不是特定于Go的。它们也存在于Java (和大多数其他语言)中，尽管Java有一种通过使程序更复杂的类加载器来部分解决这个问题的机制。注意，Go将在编译时报告所有不兼容情况，而在Java中，有些不兼容只在运行时触发(因为后期链接)。

Java工具链没有版本的概念。它由外部工具maven提供。我相信，到Go变得更加成熟和流行时，将出现一个类似的标准依赖管理工具。