-1

So I have a project that I want to use some bit of pieces of the Docker CLI code for. It uses modules. Docker CLI does not.

The weird thing is, that at some point I had this working, but I had to switch branches and now I cannot get it to build again.

My go.mod looks like this:

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
)

I have tried removing the vendor directory, I have tried removing $(go env GOCACHE), I have even tried removing the pkg/mod directory. I have tried building with and without -mod=vendor. I have even tried building using a Dockerfile, with and without --no-cache.

Every time, the result is the same:

github.com/docker/cli/opts/config.go:15:12: undefined: swarm.ConfigReference

But, and this is the thing that boggles me, that is not what it says on any version of opts/config.go on line 15. It says swarmtypes instead of swarm which is correct. Grepping for swarm.ConfigReference in the project directory yields no results. I also tried grepping strace output of go build for config.go, no results other than this error. Edit: actually strace was truncating the path, go build does actually open the file. But I check line 15 in the file at the absolute path shown to be opened and it says swarmtypes not swarm.

Where is go build getting this code from?

Edit: fixed, I was chasing ghosts as go build was reporting the actual type instead of the import alias. Thanks to Peter below.

For reference, this actually builds (notice it uses a never version of 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
)
canned.ham
  • 9
  • 2
  • Please point out which library has that source file you're referring to. You may try checking out that library from github with corresponding tag (which you specify in go.mod), then check if the file has the right or wrong lines. – hsnkhrmn Feb 03 '20 at 07:47
  • I added more of the path. The full path obviously depends on whether it is taken from pkg/mod or vendor, not that it matters, result wise. The problem is that the project is not using semantic version tags, the version in go mod is what go makes of it when you add master. – canned.ham Feb 03 '20 at 07:50
  • swarmtypes is an alias for [package swarm at docker/docker/api/types/swarm](https://godoc.org/github.com/docker/docker/api/types/swarm) (see the import statement in config.go). The error message uses the canonical package name, that's all. You have to find a compatible version of that package to build successfully. – Peter Feb 03 '20 at 08:02
  • Ahhh... that makes sense. I did notice the import alias, but wrongfully assumed the error message should use the alias (arguably it should). I am still puzzled as to why it was compiling last week, but at least I won't be chasing ghosts anymore. Thanks :) – canned.ham Feb 03 '20 at 08:05

1 Answers1

1

The relevant import is here:

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

According to your go.mod file, you are using github.com/docker/docker v1.13.1. So go build is getting the code from that module at that version: https://github.com/moby/moby/tree/v1.13.1/api/types/swarm

It may either fetch the code for that module from a proxy (by default proxy.golang.org), or directly from github.com.

The compiler's error message for this case could probably be improved — in my opinion it should refer to the renamed package (swarmtypes) rather than the name declared in the package statement of the imported package. If you can reproduce the poor diagnostic with a current version of the Go toolchain, please file an issue at https://golang.org/issue/new.

bcmills
  • 4,391
  • 24
  • 34