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 (ie 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

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 2

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 3

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 GOPATH s 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 4

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.

Answer 5

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 6

At my company I created Virtualgo to make managing multiple GOPATH s 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 7

对我来说，一个工作区 + Godep是最好的。

Answer 8

I follow KISS - one GOPATH, two go paths:

export GOPATH=$HOME/go:$HOME/development/go

That way third party stuff goes in a central place (package install uses the first path entry by default), and I can flexibly move my projects elsewhere, at the second path entry.

Answer 9

You might want to try the direnv package.

https://direnv.net/

Answer 10

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