Add versioned dep list to each project in Gopkg.lock

[sdboyer]

While it's not possible as long as we're operating in a vendor/-bound world, we do expect to eventually be free of that. Once we are, it'll be possible to incorporate more than one version of a project in a binary.

The exact circumstances under which we'd want to do this would vary (and most of the time, we do not, as it has a lot of nasty potential side effects). One big one is minimizing (or removing) the risk of combinatorial explosion in the solver, as @rsc laid out.

Doing so, however, entails an addition to Gopkg.lock - each listed project needs to indicate which versions of the other dependent projects it's depending on, so that there's no ambiguity.

While we don't need to actually do anything with this information today, it'd be handy to add, because it surfaces project-to-project dependency information in a way that's not visible in the lock right now. Such information could well be useful for third-party tools, and by putting it into the lock, it removes the need to invoke some combination of dep status for them to read the information.

[haikoschol]

One third-party tool this would be useful for is the OSS Review Toolkit. Specifically the analyzer, which constructs a dependency tree for the project under review. I'm currently working on adding Go support, and for the time being, we will go with a flat list of dependencies.

Not directly relevant to this issue, but what would be even more useful is if Gopkg.lock included fully qualified URLs for each dependency (i.e. including the type of VCS). AFAIK, right now the only options we have are

• reimplement the logic that yields a proper URL from an import path
• download every dependency again (with go get) and infer the VCS type from its location in GOPATH