> You are trying to build Go in a way it wasn't designed for. Yeah, I think his issue is with Go's choice to not search the current directory. The go tools sh

> You are trying to build Go in a way it wasn't designed for. Yeah, I think his issue is with Go's choice to not search the current directory. The go tools should let you use the current directory, and the "best practice" would have been vendoring to start, relative to the current directory. Then suddenly you see no GOPATH would be necessary at all! For example: % mkdir $proj % go get github.com/$dep1 % go get github.com/$dep2 % vim main.go % find . ./main.go ./github.com ./github.com/$dep1 ./github.com/$dep1/somepkg ./github.com/$dep2 ... See, then main can import github.com/$dep1/somepkg, and it would be properly versioned and vendored! It falls out in a bunch of other ways of being nicer too IMO. The currently GOPATH design encourages untracked and complected dependencies, where we're at 1.8 of the toolchain and we're still changing packaging behavior of dependencies.