I recently found this extremely old post. It’s not particularly relevant anymore, but history is history.

Every once in a while when I set up a new Go project, I forget how exactly I had set up my previous project’s environment to just “work” how I desire it to.

Hopefully this post helps you, too.

Like many, I was initially excited that Go (almost) forces a strict environment setup: you put code in a workspace, and Go behaves as you expect it to. Trying to fight against it can be the source of a few well-earned headaches - it’s not what you’re supposed to do. Thus, I don’t really recommend you do so until you’ve become comfortable with the toolchain.

Having been spoiled by PHP’s Composer and Python’s pip + virtualenv, Go’s built-in management of packages tends to become cumbersome after you’ve written a few tools and need to “freeze” them along with their dependencies.

There are currently a huge number of solutions for managing third-party dependencies. I have personally chosen gvp and gpm. They are both simple shell scripts.

gvp

gvp manages your $GOPATH. Running gvp init results in a .godeps directory and a few sub-directories.

gvp in sets $GOPATH to the .godeps directory.

gpm

gpm is responsible for actually “managing” dependencies. You create a Godeps file, which looks like:

github.com/chrsm/gunfuddle 29cc92e55516a1131b25272a2a64b11ec5c639a0
github.com/other/dependency TAG
...etc

and then use gpm install, which uses go get under the hood to install the packages, and then it checks out the revision you pointed to in your Godeps file.

fatih/vim-go

Fatih developed a one-stop plugin for writing Go in vim. It contains a handful of useful Go tools and other goodies like UtilSnips integration.

Multiple Go versions

I also use a tool called gvm to manage my actual core Go installation. With gvm, I can install multiple versions of Go and switch between them with no hassle.

Making “intellisense” play nice

nsf wrote gocode, an autocomplete daemon for Go code. It’s absolutely fantastic. It works 100% perfectly when you have a standard Go workspace. Even when you don’t, it seems to work well for the most part as the server now accepts path-related information from the client.

If you, like me, do not have a standard setup - you’ll want to make sure you go install -v package after you run gpm install, so that Go will build files that gocode actually reads in order to give you feedback.