There is a problem with the current design of godep save -r.
godep save -r
Some projects use godep save -r to rewrite import statements in files that import their dependencies. This makes the repo self-contained—having no external dependencies—so it can be built with an ordinary “go get” command while retaining reproducibility.
Now consider a repo r that contains two packages: command r/c and non-main package r/p. Command r/c imports r/p, which imports an external dependency d. There are (at least) two ways one might rewrite import statements when copying d into r:
The first method above is the current behavior of godep save -r.
Consider another package u that imports both r/p and d. The current behavior means that r/p no longer imports d, it imports r/Godeps/_workspace/src/d. Package u cannot interchange types defined in d with types from r/Godeps/_workspace/src/d—they are distinct packages.
(Attempting to require u to import r/Godeps/_workspace/src/d instead of d does not eliminate the problem, because u may depend on d indirectly, through yet another repo q, which may or may not itself have copied and renamed d to q/Godeps/_workspace/src/d. There is nothing u can do to resolve the difference between r/Godeps/_workspace/src/d and q/Godeps/_workspace/src/d.)
This is not hypothetical. Users of godep have occasionally encountered this situation already.
The second method above would avoid this problem, but introduce a new one: the author of r needs to rerun godep save -r every time they edit r/p and want to test the results in r/c. This makes the development workflow more cumbersome.
What do you think of the second method? We have not yet tried it, so we don’t have a good idea of how cumbersome it would be in practice.
Is there another approach that avoids both of these problems?
What about a third method?
Put another way, basically treat r/c as if it were a totally different repository. Still has the problem of having to run godep save -r to pull in changes to r/p in r/c, but drives home the fact that only package mains should vendor.
vendor/ provides some of this as you can have multiple vendor folders at different levels. I'm not yet sure we should support that and instead only make a top level vendor/ folder with everything flattened down into it with a way smarter system for package resolution.
How are people handling this in practice?