I really like Go, and have been getting into it quite a bit. It's powerful, quick, and fits in nicely as a "native code" utility language, which I dig. However, the first thing the OP talks about, $GOPATH, really fricken annoys me. I know that's sort of silly, but hey.
Are there any good fixes for this at all? What other ways of tackling the dev env are there for Go?
Ah hah! I wish I could give you more than just an upvote, as that's awesome, and I really wish I'd thought of it first. I'll give it a try, thanks very much!
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".
Don't try to work around it, but embrace $GOPATH instead. As soon as you put your project inside $GOPATH/src (or ${GOPATH%%:*}/src if you want to be pedantic), things work flawlessly, esp. all the tooling around Go that expects to work with $GOPATH.
In my company, we have the convention for our internal Go projects to be checked out below $GOPATH/src in a $company_name/$project_name hierarchy, and that's also what you'd use as import path.
You don't have to use go get, you can set gopath, then ignore it and use whatever paths you want - go run/go build will happily build for you no matter where the files are, though obviously go get would use the gopath.
You don't have to use go get though, you can define import paths any way you like (e.g. relative to project pkg) and go run or go build /path/to/my/project to build your project with the -o flag to specify the output binary. As long as dependencies are where you specify, it'll happily build. So if you want per project dirs, it's perfectly possible to do that with the standard tools, but when sharing code people will expect to be able to go get etc. and relative import paths are frowned upon.
So if you wish you can pretty much ignore GOPATH, if you're not go getting dependencies, but if you're sharing it might be best to bend to the consensus which is to have one gopath and put all your projects there (they can of course be within project dirs within that gopath or linked to elsewhere).
I use GOPATH only inside of a wrapper script that sets GOPATH to the directory for the current project. All libraries are stored alongside my project code in source control. I use go get when adding/changing libraries, but remove the .git folder when doing so.
Are there any good fixes for this at all? What other ways of tackling the dev env are there for Go?