> I think this behaviour can be explained in part because docker/docker isn't yet a vgo package, so the pain below may only be a teething pain which won't exist in the end. But I'm unsure on that point.
If docker/docker/client has substantially fewer dependencies than docker in geneneral, it should ideally be defined as a separate vgo module. I suspect that would mitigate most of the problems from extraneous dependencies.
> 1. Why does vgo take 8 minutes to run the first time?
Vgo doesn't do many things in parallel at the moment. We know that's not ideal, and it will get better.
https://golang.org/cl/119055 (just committed) should help quite a bit. How bad is the situation with a vgo built from commit 0a6cdd775a6812169f1b0e5c6bfb27d35d50cbef or later? (I just timed it at 3m18s on my machine, but YMMV.)
> 2. Why is vgo producing so many exit status 1 errors? Is this expected?
I'm not sure why it's doing that. I didn't see any “exit status 1” when I tried a `vgo build` on your example.
At the very least, the fact that the output looks buggy is cause to investigate. Could you file a bug in the Go issue tracker? (Use the prefix “x/vgo:” and please provide the versions of go, vgo, and the git command. We've had some trouble before with older versions of git that ship with some distros.)
> 3. Should vgo be looking at all of the transitive dependencies of docker/docker?
That's an interesting question.
When vgo first runs on a non-vgo repository, it generates a module definition for the root directory of that repository.
That module definition applies to the whole module: if some package imported by docker/docker/client comes from a package that depends on `foo v1.0.0`, and docker/docker/somethingelse imports a package whose module depends on `foo v1.2.0`, then the entire docker/docker module depends on `foo v1.2.0`.
If we didn't find the transitive requirements of the entire module, then when someone else incorporates your package into their program (that happens to also import docker/docker/somethingelse), they would get `foo v1.2.0` instead of the `foo v1.0.0` that you had tested against, even though they are using the same version of the docker/docker module that you were.
So we have to download at least enough of the transitive dependencies to be able to see the whole module graph. If our sparse `git fetch` logic is working correctly, we shouldn't have to download entire repos for those dependencies: just the go.mod files (or supported legacy lock files) should suffice.