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 to a project's dependencies, seems to be all over the place.

What (or is there) a common best practice around using a single or multiple Go workspaces (i.e. definitions of $GOPATH) while working on various Go projects? Should I be expecting to have a single Go workspace that's sort of like a central repository of code for all my projects, or explicitly break it up and set up $GOPATH as I go to work on each of these projects (kind of like a python virtualenv)?

Answer 1

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).

Answer 2

I think it's easier to have one $GOPATH per project, that way you can have different versions of the same package for different projects, and update the packages as needed.

With a central repository, it's difficult to update a package as you might break an unrelated project when doing so (if the package update has breaking changes or new bugs).

Answer 3

Just use GoSwitch. Saves a heck of a lot of time and sanity. Add the script to the root of each of your projects and source it. It will make that project dir your gopath and also add/removes the exact bin folder of that project to path. https://github.com/buffonomics/goswitch

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

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 6

Using one GOPATH across all of your projects is very handy, but I find this to only be the case for my own personal projects.

I use a separate GOPATH for each production system I maintain because I use git submodules in each GOPATH's directory tree in order to freeze dependencies.

So, something like:

~/code/my-project
- src
  - github.com
    + dependency-one
    + dependency-two
    - my-org
      - my-project
        * main.go
        + package-one
        + package-two
- pkg
- bin

By setting GOPATH to ~/code/my-project, then it uses the dependency-one and dependency-two git submodules within that project instead of using global dependencies.