Whats a good best practice with Go workspaces?

Question

I\'m just getting into learning Go, and reading through existing code to learn \"how others are doing it\". In doing so, the use of a go \"workspace\", especially as it relates

Answer 1

You might want to try the direnv package.

https://direnv.net/

Answer 2

If you just set GOPATH to $HOME/go or similar and start working, everything works out of the box and is really easy.

If you make lots of GOPATHs with lots of bin dirs for lots of projects with lots of common dependencies in various states of freshness you are, as should be quite obvious, making things harder on yourself. That's just more work.

If you find that, on occasion, you need to isolate some things, then you can make a separate GOPATH to handle that situation.

But in general, if you find yourself doing more work, it's often because you're choosing to make things harder.

I've got what must be approaching 100 projects I've accumulated in the last four years of go. I almost always work in GOPATH, which is $HOME/go on my computers.

Answer 3

One workspace + godep is best as for me.

Answer 4

At my company I created Virtualgo to make managing multiple GOPATHs super easy. A couple of advantages over handling it manually are:

• Automatic switching to the correct GOPATH when you cd to a project.
• It integrates well with vendoring tools
• It also sets the new GOBIN in your path, so you can use the executables installed there.
• It still has your original GOPATH as a backup. If a package is not found in the project specific workspace it will search the main GOPATH.

Answer 5

I used to use multiple GOPATHs -- dozens, in fact. Switching between projects and maintaining the dependencies was a lot harder, because pulling in a useful update in one workspace required that I do it in the others, and sometimes I'd forget, and scratch my head, wondering why that dependency works in one project but not another. Fiasco.

I now have just one GOPATH and I actually put all my dev projects - Go or not - within it. With one central workspace, I can still keep each project in its own git repository (src/<whatever>) and use git branching to manage dependencies when necessary (in practice, very seldom).

My recommendation: use just one workspace, or maybe two (like if you need to keep, for example, work and personal code more separate, though the recommended package path naming convention should do that for you).

Answer 6

Try envirius (universal virtual environments manager). It allows to compile any version of go and create any number of environments based on it. $GOPATH/$GOROOT are depend on each particular environment.

Moreover, it allows to create environments with mixed languages (for example, python & go in one environment).