|
|
|
|
|
|
by monjaro
4459 days ago
|
|
|
Please don't use this. It doesn't do anything you can't do with the default go tools, and it doesn't follow the standard project organization. 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. |
|
|
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.