Not sure what you mean by other ways to tackle the dev environment. You need GOPATH, it's totally non-optional for any nontrivial code. Try it for a bit before you look for an alternative, it's actually quite elegant.
It's quite possible that I will be better off just embracing it, but I do so much development on this machine with close to a dozen languages that I've developed my nice project setup to handle it all, and it seems a little frustrating to have to change it all, I guess. I sort of prefer per-project stuff overall.
I may end up using a dedicated VM for it, perhaps, to get around it :)
Heh, I was wondering that myself, but I try not to get too hungup on votes :)
Per project is just going to be a pain in the butt, honestly. It means you'll need to constantly swap out the gopath, and there's really very little harm in having all your go code in one giant gopath. The only time it is a problem is if you use different branches of a package for different projects. That has been very rare in my experience, hopefully it will be in yours as well.
However, I do know some people that have a gopath per project... you certainly can do it, it's just more work. But what you do need is some sort of gopath. It's fundamental to the language. In theory you could probably build without one if all your imports were relative, and you checked out code without go get... but you'd end up with non-idiomatic go code that no one else would touch with a ten foot pole, and you'd lose a lot of the cohesiveness of the tooling.
What is elegant about the use of an environment variable? From what I can see on the net, the requirement for all GO projects to exist within $GOPATH mainly seems to confuse and annoy people.
Though you could have separate $GOPATH for each project. Note that $GOPATH can be colon delimited (though `go get` will download packages to the first directory in the list).
You could use something like http://swapoff.org/ondir.html to switch out $GOPATH depending on which directory you are in in your shell.
It's elegant, because all code generally lives in a repo online somewhere, and by having a canonical place for that code to live on your local disk, it's trivial to have code that references other code that lives online somewhere else, and you can get all of it with a single command.
If I go get your package, and your package uses someone else's package, I get their code too. It's quite elegant. And all it needs is one little environment variable that says "store my go code here".
