docker/go-docker

Is this SDK discontinued?

EugenMayer opened this issue · 5 comments

EugenMayer commented

Seems like this is more a mirror of something which is worked on internally - there is nothing happening anymore, no questions answere or pull requests handled?

Should one build on this at all?

cpuguy83 commented

It's certainly not been updated or ever officially released/announced.

There are two main things that this was trying to resolve:

  1. Having a tag with all the correct commits for any given Docker release (moby doesn't have releases).
  2. Not depending on a vendor dir which simplifies things for certain vendoring/build tools.

For point 1, this can be dealt with by using the repo at https://github.com/docker/engine which should have proper tags since Docker 18.06.

Point 2 is definitely still a problem.

  • 👍2
EugenMayer commented

@cpuguy83 thank you for the clarifcation. Maybe for a more hands-on decision making for people stumbling upon this:

  1. one does need a golang docker library to stop/start containers, to save/load images, to pull/push images
  2. One would need to authenticate against docker while doing 1)

Could you comment what you would advice?

I have some hands-on experiences at least to share

For 1)
I implemented authenticated pull and load/save of images. It was ok, it feels fairly raw though, the library feels incomplete, for load also error prone and overall, it works, but it feels "not too well".

For 2) i had to combine this library with github.com/docker/cli/cli/config and use it to retrieve the authentication data. For configs where credentials are saved inside config.json this works, for credential helper, this seems to be broken (even though it is implemented) - at least under OSX the credentials helper is not called correctly ( docker/cli#1337 )

So overall https://github.com/docker/cli seems very complete or at least very advanced and seem to offer all of this library: https://github.com/docker/cli/tree/master/cli/command - i guess the bottom line would be, does it then make sense to use go-docker or maybe use docker/cli or maybe you have an even better advice? Thanks!

cpuguy83 commented

The official client package is github.com/docker/docker/client
This is the client library that docker/cli uses.

You can get this from https://github.com/docker/engine (with the desired release tag) or directly from github.com/moby/moby which is effectively always being updated since there are no tags to target (outside of really old tags from before the Moby transition).

EugenMayer commented

Sorry, i am not sure what you mean by

You can get this from https://github.com/docker/engine ..

do you mean using this as the go package using https://github.com/docker/engine/tree/master/client as the include ..

  1. docker/go-docker seems to be a bad choice
  2. To some up https://github.com/docker/cli seems the wrong choice also
  3. https://github.com/docker/docker .. which is redirected to https://github.com/moby/moby is what you point to to the best reference

Now i see that https://github.com/docker/engine and https://github.com/moby/moby have both "client" as a folder - thats basically the same code but just packaged in those different projects? Why did that never got extracted into an own project then so both can include it? Or are they any different?

Thanks a lot already!

cpuguy83 commented

All development is done on github.com/moby/moby
Docker releases of the engine component are done from github.com/docker/engine
The docker/engine repo is a fork of moby/moby for the purposes of doing Docker releases. This is where backports for Docker patch releases go as well.

The actual go packages are github.com/docker/docker/<package>, which can technically come from anywhere so long as you setup your go environment correctly.... e.g. by cloning github.com/docker/engine to <GOPATH>/github.com/docker/docker, or in <PROJECT_PATH>/vendor/github.com/docker/docker.
This is possible because each package is annotated with a "canonical" import path (to which the prefix to all packages in the repo is github.com/docker/docker).

Why did that never got extracted into an own project then so both can include it?

The docker/engine repo is a literal fork of moby/moby as mentioned above.
The client and API types were extracted to a separate project at one point, but it proved too cumbersome to maintain and contribute to.

Hope this helps.