ping @dennwc

I'm confused by this. Did you simply copy the vendored package into your own directory? What is the point of that?

go-dockerclient had a dependency on docker-swarm which pulled a ton of external dependencies. Instead of forking go-dockerclient I vendored the docker dependency here and removed the swarm capabilities which we don't need anyways. Still has some dependencies to smaller repos but we can strip them as time passes

Another issue addressed by this is the ridiculous instability of dep and the docker repository in general. I got failing builds everywhere because dep was unable to copy some unrelated go files (.pem test fixtures). Vendoring it in here will resolve this, but we might have to update this if docker releases breaking changes.

I see. Have you considered just forking go-dockerclient instead and using that repo as a proper vendor directory?

Yes, I did. I don't want to give the impression though that it's officially maintained and an alternative to go-dockerclient because it's not.

I would also prefer to just use http.DefaultClient to talk to Docker but I don't have the time to dig in and it also seems like there's more to it (like handling their streams, properly reading auth data, ...)