Whats a good best practice with Go workspaces?

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


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


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.


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.

Tags:

Package

Go