[zeveb]

What I don't get is why more folks don't just use per-project GOPATHs.

I have all my stuff in $PROJECT/src/$PROJECT, and all the dependencies are git submodules in $PROJECT/src/, and it all Just Works. Perfectly. git submodule is a bit of an annoyance, but it works. Anyone fetching my project just checks everything out, and it all Just Works™.

It's a lot better than using a dependency-management tool and shared GOPATH, at least in my experience.

[camus2]

> What I don't get is why more folks don't just use per-project GOPATHs.

because that's not how go works. You need extra work to make it work. That's not up to debate anymore anyway, dep will be the official package manager and will be merged with the rest of the official ecosystem.

[zeveb]

What do you mean 'that's not how go works'? Go provides GOPATH: using a different GOPATH for each of my projects works, and it works really well.

> You need extra work to make it work.

What extra work? I set GOPATH, and everything just works. What more is there?

> That's not up to debate anymore anyway

Neither were type aliases, until they were, except they aren't.

I have no idea what dep adds that using the standard GOPATH doesn't do: I've read the background and the docs, and I'm familiar with using the vendor directory in the past; frankly, now that I've switched to using GOPATH all of those things look like a mistake. It all reads like tha Javafication of Go.