Requires 32 external dependencies, mostly unnecessary

[ahmetb]

Here's the dependency graph of this package: https://godoc.org/github.com/fsouza/go-dockerclient?import-graph&hide=2

When I vendor this repo with govendor, here's the list of packages I'm getting:

1. github.com/Azure/go-ansiterm
2. github.com/Azure/go-ansiterm/winterm
3. github.com/Microsoft/go-winio
4. github.com/Sirupsen/logrus
5. github.com/docker/docker/api/types/filters
6. github.com/docker/docker/api/types/mount
7. github.com/docker/docker/api/types/swarm
8. github.com/docker/docker/api/types/versions
9. github.com/docker/docker/opts
10. github.com/docker/docker/pkg/archive
11. github.com/docker/docker/pkg/fileutils
12. github.com/docker/docker/pkg/homedir
13. github.com/docker/docker/pkg/idtools
14. github.com/docker/docker/pkg/ioutils
15. github.com/docker/docker/pkg/jsonlog
16. github.com/docker/docker/pkg/jsonmessage
17. github.com/docker/docker/pkg/longpath
18. github.com/docker/docker/pkg/pools
19. github.com/docker/docker/pkg/promise
20. github.com/docker/docker/pkg/stdcopy
21. github.com/docker/docker/pkg/system
22. github.com/docker/docker/pkg/term
23. github.com/docker/docker/pkg/term/windows
24. github.com/docker/go-units
25. github.com/fsouza/go-dockerclient
26. github.com/hashicorp/go-cleanhttp
27. github.com/opencontainers/runc/libcontainer/system
28. github.com/opencontainers/runc/libcontainer/user
29. golang.org/x/net/context
30. golang.org/x/net/context/ctxhttp
31. golang.org/x/sys/unix
32. golang.org/x/sys/windows

I'm like: WAT?!

This shouldn't be happening. I get that some functionality may require some methods implemented in docker/docker, but this is 19 packages from docker/docker.

Especially seeing dependencies like github.com/docker/docker/api/types/swarm is quite sad. The whole point of having an SDK is that we can rely on it to consume docker Remote API, independently from the revs that happen on docker/docker codebase.

Many other dependencies, like pkg/jsonmessage, this package is using offers some streaming method called DisplayJSONMessagesStream (which, by the way, is designed to "display" messages, and actually does not return some valuable data of jsonmessage provided on the API) eventually end up pulling dependencies like:

• github.com/docker/docker/pkg/term, and since this can build on windows, the following:
• github.com/Azure/go-ansiterm
• github.com/Sirupsen/logrus
• github.com/Azure/go-ansiterm/winterm
• github.com/docker/docker/pkg/term/windows

This is not ideal.

I suggest getting rid of these little dependencies and just copy/pasting parts used on these.

[rusenask]

thanks, github.com/docker/docker/api/types/swarm is actually generating a lot of pain.

[fsouza]

Hi @ahmetalpbalkan, thanks for bringing this up. I'd be happy to review and pull-in some code for some of the dependencies, as long as the copies are small (and, ideally, automated).

@rusenask what kind of pain are you referring to? go get? Thanks!

[ahmetb]

There was a comment here yesterday from "Hassan Syed", it doesn't appear here now, so let me bring that back from my inbox:

On Wed, Nov 30, 2016 at 4:49 PM, Hassan Syed notifications@github.com wrote:

It's quite crazy the creep go projects generate and how big projects do not seem to mind. Adding a dependency on docker , direct or via this client instantly adds 5 megabytes to the binary. It is 37 times worse depending on the kubernetes client.

I really want to do some go Dev/ops tools for fun but making a commitment to tracking gigantic dependency trees really kills it for me :(

[fsouza]

@ahmetalpbalkan I saw it here, it looks like he deleted it for some reason.

[hsyed]

I removed it, I was only a few days into go at the time -- it looks like a rant (it probably was) !

I figured out that the majority of the bulk was due to the large parts of the stdlib being linked in statically and that the dependency sprawl I was perceiving was just my naivity.

I was also getting my head around vendoring and go packages -- the dependency list above looks fairly standard now !

The Kubernetes client is insane though :D I have no clue what it could be linking in to make it build 37 mb hello world binaries on a mac.

[fsouza]

@hsyed thanks for clarifying! :D

[dennwc]

I also think that such a large dependency graph for a client library is far from ideal.

We use this library for a few projects, some of them use it for running tests. To give a context, we are running basic Go tests on CI and docker tests on other environments. Importing (and vendoring) this library significantly increases the time for each build/test to pass on CI in particular.

If it's possible to get rid of at least some dependencies by copying types/functions, this will save us a huge amount of time waiting for these CI builds to finish :)

[fsouza]

I have done some work to clean-up/copy some dependencies. It gets tricky with swarm stuff as we're exposing types from dependencies in our public API (a mistake that can't be fixed without a breaking change). I'm going to close this issue for now, but PRs are welcome.