There may be a standard project organization that "makes sense" to people familiar with Go, but based on the amount of confusion out there about this, that page is obviously not succeeding in its mission.
Consider items like these:
> The GOPATH environment variable specifies the location of your workspace. It is likely the only environment variable you'll need to set when developing Go code.
> If you keep your code in a source repository somewhere, then you should use the root of that source repository as your base path. For instance, if you have a GitHub account at github.com/user, that should be your base path.
> To compile and run a simple program, first choose a package path (we'll use github.com/user/hello) and create a corresponding package directory inside your workspace:
> $ mkdir $GOPATH/src/github.com/user/hello
Keeping the above snippets in mind, here's my thought pattern while reading the page:
So... I have only one workspace for all my work and I can set GOPATH once, in my .bashrc? Or I have one workspace per project and I need to set it differently for each project, kind of like a Python virtualenv? But then what's the difference between a "workspace" and a "project"? I do have a github account with a bunch of different projects -- err, repositories -- so that seems to reinforce the first way, but I don't typically work on them at the same time, so why would I combine them into a single Go workspace? And what's a "base path"? I must have missed that definition... nope, it's not in there, ok, I guess it's the root of where I'll put my... _new_ code? (Is it going to sync down all my repos?) But wait, here's an example where they say to create a Go "package" directory github.com/user/hello -- AHA! A Go "package" is like a git repository! Wait, that doesn't make sense... I'm planning to check this whole directory structure into github as a single project -- err, repo. Or am I not supposed to do that? But then I'd have to recreate all this on any machine where I want to work... is that really the intent? Yep, sure enough, they eventually say I should put the package directory into its own repo. So yes, I'm really only supposed to have one workspace for all my Go projects (I think). I wonder how Go manages dependency isolation for completely unrelated packages -- err, projects? -- that have the same output filename but are in the same workspace? Anyway, it sure would be nice to have a shell script or something to set up the workspace scaffolding for me, since I'm not supposed to check it into github...
And so we end up with folks like the OP doing exactly that. I'm sure there's a way to beat your head against this stuff until you eventually "get it", but it ought to be far easier than that to teach people coming from other environments.
At the very least, it would be helpful for this page to start by explicitly defining the mappings between the way Go uses words like "workspace", "package", "project", etc. and the way other languages/environments use them.
You can use gvp (https://github.com/pote/gvp) to isolate your workspaces (GOPATHs, really) for each of your projects, you can then include your dependencies in your project's repo or have a Godeps file specifying versioning which you can use with gpm (https://github.com/pote/gpm).
This is the worst thing about Go, in my opinion. I have one directory for my Go projects, and another for everything else. Go takes too much control away from the programmer.
"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." — Doug Gwyn
This is the worst thing about the Go build system, is what you mean. I get annoyed by the classpath-seeming directory tree Goland demands (although producing fast binaries I can upload to servers that have never heard of Golang is a fine consolation prize), so oftentimes I just treat Golang the way I do Python or Ruby, with random .go files all over the place, using "go run".
I don't think the annoying thing about it is the classpath-like thing (and even if it were, it's at least not as bad as that, not requiring a directory for each path component), but the fact that everything is predicated on this assumption that I'm only working on one thing (or ecosystem of things). I don't want project A and project B to be forced to share dependency versions, but Go makes you go to some pretty bizarre lengths to avoid that. I'd rather have a directory for a project and have its dependencies inside that in pretty much any language/environment.
(which should only happen once per project), and all is fine in the world, because symlinks work as expected. It's not bothering me enough to have created a supplementary shell script.
Goat (https://github.com/mediocregopher/goat), which isn't especially well known, does a lot of this in a more palatable way. I prefer using it when I don't need to edit/tweak my dependencies.
I also find gpm to be quite nice and resemble npm. (https://github.com/pote/gpm)
yeah, it's sad that go doesn't come with better dep and workspace built-in
This approach has one fatal flaw. While Go can precompile dependencies for faster builds you loose this ability when breaking out of the go project organization.
If you are using CGo and need to build for your RaspberryPi you need to build on an ARM (i.e. your Pi) and there every optimization counts.
As for organizing larger projects I go with vagrant. It allows me to control my Dev environment including non-go dependencies such as ImageMagick.
Go seems very cool, but after watching many tutorials, attending a Google workshop for students on Go, and reading the docs, I'm still confused by how one is supposed to manage a Go project in the simplest way.
here is the simplest way to handle it: Just make your whole source code folder(or even your home folder) which contains all your projects to be gopath, and forget about it.
That's until you start thinking about dependency versioning.
The only way I can think of how to integrate versioning into Go's "one workspace" philosophy is to encode versions into package paths and then use import aliases to point to different versions of packages.
But that means you're spreading versioning information across all source files, and it only works if everyone decides to use this approach. So far no one does (I believe).
He even links to the guide that tells you exactly how you should be setting up a project: http://golang.org/doc/code.html
There is nothing here that requires a Makefile.