Replace github.com/docker/docker/client dependency?

[wking]

We currently depend on it here, but it pulls in a lot of apparently-unrelated Go. It would be nice to drop that heavy dep for something more focused on image transport. Perhaps github.com/docker/distribution/registry/client? Or is github.com/docker/docker/client providing a lot of added value that is unavailable in other places?

github.com/docker/docker/client also shows up as a source of Glide/Godeps issues (here and later), but I couldn't find an existing issue about dropping the client. #44 is in the same neighborhood, but think it's so old that it probably doesn't matter anymore.

[mtrmac]

docker/docker/client is a client for the “engine API”, i.e. for connecting to the docker daemon (docker-daemon: transport in c/image). That’s something entirely different from the docker/distribution registry API (docker:// in c/image).

(And #44 is neither, really; it’s a proposal about an internal implementation detail of c/image/docker, which does not call either of these packages apart from insubstantial uses of a small subset of the docker/distribution error handling code.)

---

It’s, I guess, technically possible to drop the docker/docker/client dependency and replace it with a copy of the code, or the relevant smaller subset, but at least I personally really don’t want to take on the maintenance work (especially for cross-version compatibility) for that, just to minimize dependencies. Calling out to well-maintained shared implementations is, in general, good.

---

Still, yes, bringing in a fair amount of moby can be painful, especially for projects which bring a different version of it for their own purposes. An easy-to-implement way to avoid that problem would be to introduce a build tag to stub out the docker-daemon: transport.

OTOH, I would in general much prefer for a consistent set of transports to be always available: one of the ideas of c/image is that the transport:name text format is universal in a CLI, and making it too easy for different callers to stub out various transports makes the universality of the CLI unreliable (every single program can make a slightly different choice of what transports to stub out, and users would never be sure which programs accept which inputs). The docker-daemon: transport is typically brought in by alltransports.ParseImageName, i.e. exactly into users of the library who do expose the CLI syntax to users. Right now we allow stubbing out the Linux-only transports, where a macOS version of the callers obviously all opt out, and there is no inconsistency; stubbing out docker-daemon: is different, it can well be useful to have a client on macOS.

(Users of the library that only need c/image for a specific transport and/or the image conversion capability can call in specific/subpackage.Transport.ParseReference or specific/subpackage.NewReference or something similar, without bringing in the alltransports subpackage, or any unused transports, at all. So they should already not be paying for the docker/docker/client dependency, or they have an easy way to get rid of it; as a bonus, using a transport.NewReference is more type-safe than alltransports.ParseImageName.)

[vrothberg]

Can we close this issue? I concur with @mtrmac. Unless we maintain copies of moby/moby, there is no other way around this dependencies. Even https://github.com/fsouza/go-dockerclient is depending on it, although I find it's API a bit nicer.