Godep has been pretty composable in my experience. I use Godep in a makefile to build, and it does everything in a constructed GOPATH as well.

  GOPATH := ${CURDIR}/build
  
  build:
    @env GOPATH="${GOPATH}" godep restore
    @test -d "${GOPATH}/src/github.com/user/repo" || ln -s "${CURDIR}" "${GOPATH}/src/github.com/user/repo"
    @env GOPATH="${GOPATH}" go install github.com/user/repo

I do like the look of Goop's dep format file though. The Godeps file is pretty ugly in comparison.

It is worth noting that godep recently added an import path rewrite option, which removes the need to manipulate your workspace's packages or even run the dependency tool in order to `go get` or build your code.

https://github.com/tools/godep/commit/983ff9241cead0f7e6ad0a...

Edit: Though, perhaps the final solution could be cleaner with a vendoring tool written from the ground up with the purpose of import path rewriting.

From what I can tell, goop has the same GOPATH issues as godep, but godep allows you to address it in different ways. save/restore is one way, and there is also the proxy to the go tool `godep go` which looks to be the goop approach.

Thanks for answering my questions in paragraphs 2 and 3. Not sure how paragraph 1 was useful.

I see godep as a swiss knife of tools, and different people use godep in completely different ways (which has its advantages and disadvantages). Personally, the only godep commands I use are:

  rm ./Godeps && godep save --copy=false      # Save current dep versions
  rm -rf $TMPDIR/godep && godep go build/test # build/test using saved dep versions

It's not really clear from the documentation/README how this works under the hood, so for now I have to just go by what you're saying here until I have time to actually take a closer look.

First off, I will say that I'm not a great fan of godep, so I'm not looking to advocate for it. That said:

> Godep wants you to mangle with your GOPATH. For example, `godep save` saves revisions of packages currently installed in your GOPATH and `godep restore` downloads packages into your current GOPATH. If you don't have to pollute global GOPATH, you will have to change it. This works for some people, doesn't for others.

Your $GOPATH is a list of directories, not a single directory. This is almost never useful in practice (most people should just use a single directory as their GOPATH). However, for what you're trying to do here, that would be far simpler than introducing a third-party tool, especially one that requires adoption from all project contributors.

> Goop doesn't want you to worry about GOPATH.

The $GOPATH is technically not part of the Go language (spec), but it is a language-wide idiom respected by all build tools. I'd be very nervous about a project that eschews such firm idioms in favor of its own inventions.