展平主依赖的供应商传递依赖答案

【问题标题】：Flatten vendored transitive dependencies of primary dependency展平主依赖的供应商传递依赖
【发布时间】：2019-03-07 03:24:34
【问题描述】：

我一直在将现有项目从使用通过 Glide 提供的依赖项转换为使用 Go 1.11.x module support。但是我在一个项目中遇到了一个使用我无法解决的模块的特殊情况。

内部项目“foo”的依赖项通过“go mod vendor”提供：

projects/src/foo/
    main.go
    vendor/
        ...

这在内部构建该项目时非常有用，因为非 Go 开发人员可以将项目克隆到任何位置并构建它，而无需外部代理访问来下载依赖项。

现在我正在尝试允许项目“bar”使用库“foo”构建工具。

package bar

import "internal.com/project/foo"

“go.mod”文件只包含：

module internal.com/project/bar

require internal.com/project/foo v0.0.0-...

我会通过以下方式供应商：

go module vendor

我通过以下方式构建：

go build -mod=vendor

我看到的是“foo”将从内部 git 存储库中克隆，并且它的所有依赖项都将从它们的远程 git 源下载，并且我的“go.sum”文件将使用所有瞬态更新依赖关系。但我真正想要的是只从我的内部网络中获取“foo”并让它扁平化供应商的依赖关系。理想情况下，不应有外部 http 请求。

这甚至可能吗？在直接构建项目“foo”时，“-mod=vendor”标志非常有用。但它似乎不适用于这里，因为项目“bar”不想供应商。它想要获得一个主要的依赖，就是这样。似乎 Go 模块支持并不关心扁平化供应商的瞬态依赖关系。

以前使用glide 作为包管理器时，它会从内部 git 存储库中获取“foo”，然后将其所有依赖项扁平化到我的供应商目录中。

最初以question to golang-nuts 发布，没有回复。

【问题讨论】：

【解决方案1】：

目前这种方式不起作用，只使用顶级供应商目录。来自modules help：

使用主模块的顶级供应商目录构建以满足依赖项（禁用通常的网络源和本地缓存），使用“go build -mod=vendor”。请注意，只有主模块的使用顶级供应商目录；其他中的供应商目录位置仍然被忽略。

对于这个特定的用例，我建议等到go modules 成熟。

【讨论】：