I'm refactoring a program I wrote so I can properly write tests for it. One of the first methods I'd like to test is a method that uses Docker's client API to see if a certain image exists on a Docker host.
To be able to test this method, I created an interface that matches client.ImageList
's signature:
type ImageLister interface {
ImageList(ctx context.Context, options types.ImageListOptions) ([]types.ImageSummary, error)
}
I also changed the method to test to take an ImageLister
as argument, so I can pass in an ImageLister
implementation specific to my tests.
However, in my actual code, where I pass in the "real" Docker client to the method to test, the following compilation error occurs:
ImageExists: *client.Client does not implement ImageLister (wrong type for ImageList method) have ImageList("github.com/docker/docker/vendor/golang.org/x/net/context".Context, types.ImageListOptions) ([]types.ImageSummary, error) want ImageList("context".Context, types.ImageListOptions) ([]types.ImageSummary, error)
How can I resolve this? Or is my approach bad anyway, and should I go a different route?
edit: The following program reproduces the issue I'm encountering.
package main
import (
"context"
"github.com/docker/docker/api/types"
"github.com/docker/docker/client"
)
type ImageLister interface {
ImageList(ctx context.Context, options types.ImageListOptions) ([]types.ImageSummary, error)
}
func main() {
client, err := client.NewEnvClient()
defer client.Close()
ImageExists(context.TODO(), client, "foo")
}
func ImageExists(ctx context.Context, lister ImageLister, image string) (bool, error) {
return true, nil
}
The github.com/docker/docker/
package has "vendored" its dependencies in the github.com/docker/docker/vendor
directory. While a package in a vendor/
directory is imported by it's normal import path, the types are still matched by their full path to avoid incompatibilities if a package is inadvertently imported multiple times. Because of this, when sharing types between packages, both packages need to import the dependency from the same path.
The way to handle this is to properly vendor the docker package, which means moving the packages used by docker up to the top-level vendor directory. Various tools like govendor
or glide
can do this for you, and there is work on an "official" tool for dependency management right now too.
The method declared in the interface wants local type context.Context
but the implemented method expects Context
from docker. This two entities are absolutely different types so ImageLister
interface is not implemented with *client.Client
.
I believe the problem is here:
want ImageList("context".Context...
It means your local package named "context". Since docker has a package "context" (github.com/docker/docker/vendor/golang.org/x/net/context) this fact creates a naming ambiguity and could cause some issues.
Assume we have compiled a package containing the package clause package math, which exports function Sin, and installed the compiled package in the file identified by "lib/math". This table illustrates how Sin is accessed in files that import the package after the various types of import declaration.
// Import declaration Local name of Sin
import "lib/math" // math.Sin
import m "lib/math" // m.Sin
import . "lib/math" // Sin
Use named imports to resolve this ambiguity:
import (
ctx "github.com/docker/docker/vendor/golang.org/x/net/context"
)