当顶级模块及其子模块之一分别作为单独版本导入时，如何解决冲突的 go 模块依赖关系？

Question

我的项目中有两个依赖项。go.mod:module github.com/test-org/test-repogo 1.12require (    github.com/foo/bar v1.0.0    github.com/raz/mataz v1.0.0)运行后go mod download，这两个依赖项会导致github.com/shared/dependency下载两个不同版本的 a。有趣的是，它github.com/shared/dependency包含子模块，例如：dependency  -- go.mod  -- api      -- go.mod检查下载的模块显示两个版本已下载到我的本地计算机：ls ${GOPATH}/pkg/mod/github.com/shared:[dir] dependency    [dir] dependency@v1.1.0ls ${GOPATH}/pkg/mod/github.com/shared/dependency:[dir] api@v1.2.0查看这些目录的内容：${GOPATH}/pkg/mod/github.com/shared/dependency@v1.1.0:v1.1.0 中整个存储库的文件内容，包括api带有自己go.mod文件的文件夹。${GOPATH}/pkg/mod/github.com/shared/dependency/api@v1.2.0:apiv1.2.0 中 repo 文件夹的文件内容，包括go.mod文件。最后，.go我的文件中有一个test-repo具有以下设置的文件：package test-packageimport (    "github.com/foo/bar")func MyFunc() {...bar.NewBar()...}MyFunc当我尝试运行（其他地方存在的）测试时，我收到一条unknown import path...ambiguous import...错误消息。例如go test github.com/test-org/test-repo/test-package -test.run=TestMyFunc -v:unknown import path "github.com/shared/dependency/api": ambiguous import: found github.com/shared/dependency/api in multiple modules:    github.com/shared/dependency v1.1.0 (${GOPATH}/pkg/mod/github.com/shared/dependency@v1.1.0/api)    github.com/shared/dependency v1.2.0 (${GOPATH}/pkg/mod/github.com/shared/dependency/api@v1.2.0)错误指向存储库中导入的文件import行。鉴于有两个可用版本，它不知道在我的本地文件夹中选择哪个：.gogithub.com/shared/dependency/apigithub.com/foo/barapi${GOPATH}/pkg/mod${GOPATH}/pkg/mod/github.com/shared/dependency@v1.1.0/api${GOPATH}/pkg/mod/github.com/shared/dependency/api@v1.2.0有什么方法可以使该go test调用工作（解决依赖冲突）？我的两个依赖项都没有明确要求下载完整的shared/dependency@v1.1.0，但由于某种原因它被拉进来。如果不存在，它似乎会解决问题。

Answer 1

事实证明，问题在于其中一个依赖项引用了pre-go-modulesgithub.com/shared/dependency/api的版本。

这导致 go 工具具有对子模块的模块引用，而且还对go-modules 之前版本的github.com/shared/dependency/api整个存储库进行黑盒导入。github.com/shared/dependency在这个例子中，这意味着v1.2.0有 go 模块（有一个go.mod文件），而v1.1.0没有。

将以下行添加到我的go.mod文件中能够解决该问题，并且该解决方案适用于我遇到此类冲突的多个依赖项：

replace (
    github.com/shared/dependency => github.com/shared/dependency v1.2.0
    )

请注意，此解决方案仅有效，因为我们强制对共享依赖项的引用使用支持 go-module 的版本（v1.2.0+）。

Answer 2

为了以后参考，我发现当上面的方法不起作用时，运行go get github.com/shared/dependency/api@latest似乎起作用了。replace

据推测，这会强制两个模块使用最新版本的依赖项。

Answer 3

我简单地解决了以下问题ambiguous import: found package time in multiple modules:

只需删除该mod文件，然后使用与任何现有模块名称不匹配的go mod init不同名称再次删除即可。

go mod init time-不正确

go mod init gotime-正确