Threads for tangles

  1. 1

    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/.

    1. 4

      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

      1. 2

        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.