All this is necessary because people don't expect or don't want to put their code/projects under $GOPATH/src. My take on it is don't fight the GOPATH, because a lot of Go tooling expects your code to be in a valid GOPATH.
This is one of the main reasons I hate working with go projects. I have about 50 different git repos checked out on my machine right now; written in different languages. Over they years I've worked out a structure for these repos that helps me keep track of what's where and switch between them easily.
But then go comes along and is like 'no, you MUST check this out in this particular location'. And also that location has to be 6 directory layers deep, for some reason. It's just pointlessly broken when compared to every other language, where a project is self-contained within a directory.
Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 } I mean, nobody complains that npm -g puts stuff into some weird node directory that you should never ever touch manually. Or did you ever compile a random Java project that doesn't use Maven?
I think regarding convenience Go is top notch. Regarding "weirdness" it's in the middle between Unix C and Java.
> Ok but when you hate them, why do you check them out manually? You can just mkdir $GOPATH ; go get { pkg1, pkg2, ..., pkg50 }
That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component written in go, which has at $RANDOM_LOCATION.
Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it.
>That still has the same issue of all my projects following a logical structure, except for anything written in go / with a component
>written in go, which has at $RANDOM_LOCATION.
Wellll... if you are not reeeally using Go but only for short snippets or smaller projects you can place the code anywhere you like. (Except for the external deps afaik, but even that might work with ./vendors/) In your imports you need to then use relative paths. Haven't used this coding style since some time but you can totally do that. Of course you loose some goodies like having super isolated modules but it sounds you're not after that anyway.
Disclaimer: I've used this coding style for a few 1 kLoC+ projects, but I later changed to the recommended way.
>Plus, I think `go get` doesn't work with our internal company git server, but I'm not 100% about it.
You can still manually git/hg/... clone but yeah...
