The most problematic piece of the conventional Go project layouts is its expectation that your Go code resides in a repository of its own as a subdirectory of GOROOT. I’d really like the tools to accept environments where GOPATH is the root of a version control repository rather than a subdirectory of src/.
Err, typo: s/GOROOT/GOPATH. My general concern is that many organizations find it useful to maintain a single, large repository for all of their projects rather than one-repo-per-project (ex: Google, Facebook, …). This isn’t something that godep handles. The ability to commit everything under a GOPATH (including vendor’d code), or even code across different languages (such as when you have .proto files to share), simplifies many workflows.
The most problematic piece of the conventional Go project layouts is its expectation that your Go code resides in a repository of its own as a subdirectory of GOROOT. I’d really like the tools to accept environments where GOPATH is the root of a version control repository rather than a subdirectory of src/.
I don’t understand your comment, can you clarify? GOPATH has no enforced relation to GOROOT. For example I have GOPATH=$HOME and GOROOT=/usr/local/go.
Also I think people forget that GOPATH is a list of paths, so you could have something like GOPATH=project1:project2:stdlib
Err, typo: s/GOROOT/GOPATH. My general concern is that many organizations find it useful to maintain a single, large repository for all of their projects rather than one-repo-per-project (ex: Google, Facebook, …). This isn’t something that godep handles. The ability to commit everything under a GOPATH (including vendor’d code), or even code across different languages (such as when you have .proto files to share), simplifies many workflows.