时间戳

首页 > 解决方案 > `go build` 从哪里获取代码？

docker - `go build` 从哪里获取代码？

问题描述

所以我有一个项目，我想使用一些 Docker CLI 代码。它使用模块。Docker CLI 没有。

奇怪的是，在某些时候我有这个工作，但我不得不切换分支，现在我无法让它再次构建。

我的 go.mod 看起来像这样：

go 1.13

require (
    github.com/docker/cli v0.0.0-20200129215115-2079e743c493
    github.com/docker/docker v1.13.1 // indirect
    github.com/docker/go-connections v0.4.0 // indirect
    github.com/docker/go-units v0.4.0 // indirect
    github.com/imdario/mergo v0.3.8 // indirect
    github.com/mattn/go-shellwords v1.0.9 // indirect
    github.com/pelletier/go-toml v1.6.0 // indirect
    github.com/sirupsen/logrus v1.4.2
    github.com/spf13/afero v1.2.2 // indirect
    github.com/spf13/cast v1.3.1 // indirect
    github.com/spf13/cobra v0.0.5
    github.com/spf13/jwalterweatherman v1.1.0 // indirect
    github.com/spf13/pflag v1.0.5 // indirect
    github.com/spf13/viper v1.6.1
    github.com/xeipuuv/gojsonschema v1.2.0 // indirect
    golang.org/x/sys v0.0.0-20200116001909-b77594299b42 // indirect
    golang.org/x/text v0.3.2 // indirect
    gopkg.in/ini.v1 v1.51.1 // indirect
    gopkg.in/yaml.v2 v2.2.7
    gotest.tools v2.2.0+incompatible // indirect
)

我试过删除供应商目录，我试过删除 $(go env GOCACHE)，我什至试过删除 pkg/mod 目录。我尝试过使用和不使用 -mod=vendor 进行构建。我什至尝试过使用 Dockerfile 构建，有无 --no-cache。

每次，结果都是一样的：

github.com/docker/cli/opts/config.go:15:12：未定义：swarm.ConfigReference

但是，这让我感到困惑，这不是它在第 15 行的任何版本的 opts/config.go 上所说的。它说swarmtypes的不是swarm哪个是正确的。在项目目录swarm.ConfigReference中搜索不会产生任何结果。我还尝试为 config.go grepping go build 的 strace 输出，除此错误外没有其他结果。编辑：实际上 strace 截断了路径， go build 确实打开了文件。但是我在显示打开的绝对路径处检查文件中的第 15 行，它说swarmtypes不是swarm。

go build 从哪里获取此代码？

编辑：修复，我在追鬼，因为 go build 报告的是实际类型而不是导入别名。感谢下面的彼得。

作为参考，这实际上是构建的（注意它使用了一个从不版本的 docker/docker）：

require (
    github.com/containerd/containerd v1.3.2 // indirect
    github.com/docker/cli v0.0.0-20200130152716-5d0cf8839492
    github.com/docker/distribution v2.7.1+incompatible // indirect
    github.com/docker/docker v1.4.2-0.20200201180422-513b207b002d // indirect
    github.com/docker/go-connections v0.4.0 // indirect
    github.com/docker/go-units v0.4.0 // indirect
    github.com/imdario/mergo v0.3.8 // indirect
    github.com/mattn/go-shellwords v1.0.9 // indirect
    github.com/opencontainers/go-digest v1.0.0-rc1 // indirect
    github.com/opencontainers/image-spec v1.0.1 // indirect
    github.com/pelletier/go-toml v1.6.0 // indirect
    github.com/sirupsen/logrus v1.4.2
    github.com/spf13/afero v1.2.2 // indirect
    github.com/spf13/cast v1.3.1 // indirect
    github.com/spf13/cobra v0.0.5
    github.com/spf13/jwalterweatherman v1.1.0 // indirect
    github.com/spf13/pflag v1.0.5 // indirect
    github.com/spf13/viper v1.6.1
    github.com/xeipuuv/gojsonschema v1.2.0 // indirect
    golang.org/x/sys v0.0.0-20200116001909-b77594299b42 // indirect
    golang.org/x/text v0.3.2 // indirect
    gopkg.in/ini.v1 v1.51.1 // indirect
    gopkg.in/yaml.v2 v2.2.7
    gotest.tools v2.2.0+incompatible // indirect
)

标签： dockergogo-modules

解决方案

相关导入在这里：

    swarmtypes "github.com/docker/docker/api/types/swarm"

根据您的go.mod文件，您正在使用github.com/docker/docker v1.13.1. go build从那个版本的模块获取代码也是如此： https ://github.com/moby/moby/tree/v1.13.1/api/types/swarm

它可以从代理（默认情况下）获取该模块的代码，也可以proxy.golang.org直接从github.com.

对于这种情况，编译器的错误消息可能会得到改进——在我看来，它应该引用重命名的包 ( swarmtypes)，而不是在package导入包的声明中声明的名称。如果您可以使用当前版本的 Go 工具链重现糟糕的诊断，请在https://golang.org/issue/new提交问题。

推荐阅读