A typical stroll in goworkon land


A typical stroll in goworkon land

After a few weeks working on it and with it too, I have removed most of the urgent papercuts of goworkon.

So, now that i got that out of the way, I can give a little tour on how to use goworkon v0.1alpha1.


The start is still a bit bumpy but far from painful.

Assuming you have installed goworkon (in my case I just used one of my envs at that time and just ran go get -u github.com/perrito666/goworkon and voila.) you will need to add something to your ~/.bashrc (you might use another shell, I can’t guarantee this will work there.

The first thing you need to do is source the provided bash file, in my case it was just:

source $GOPATH/src/github.com/perrito666/goworkon/goactivate but

I did use the absolute path instead because for this I removed my GOPATH declaration from the .bashrc file.

This will make the goactivate command available in your shell. Since procesess running on your shell cannot directly change Env variables, goactivate solves that by parsing the output of goworkon switch and setting the variabls from a bash function.

There is a bit more to be set in .bashrc but we will see this in the future.

Once all is set, we can start.

First environment

When running goworkon for the first time, you will be prompted for a working $GOROOT this is necessary because we will compile go from source for each new version and its only requirement is a $GOROOT newer than 1.4.

Note: In future versions this will be most likely guessed and the path upgraded with each new install of go

To create an envinronment we must run

goworkon create [--go-version=1.7] <envname> <envabspath>

What happens here?:

Create will perform the following actions:

  • If the version of go is not requested, the latest version will be guessed from the go website.
  • If the version of go is not installed, it will be downloaded and compiled.
  • If envname exists it will be a noop.
  • Store all the data for the environment in ~/.local/share/goworkon/configs/.json which you can edit to suit your needs although toos are provided for the relevant parts and will be provided for the rest in next releases.

What I did for my main work machine is.

goworkon create --go-version=1.7 default /home/myuser/environments/default

The environment path (which will be the $GOPATH) is not created until you go get something.

Setting a default

For various reasons I keep a “jack of all trades” environment which I like to be always set when I enter my shell. This is called the default environment and you can pick any of yours.

I chose default, so I ran.

goworkon set default default

To aid this I added to the end of my ~/.bashrc the following:

goactivate default

Which makes sure I always land in my bash with default in the path.

Switching to other envs.

Assuming you are like me, default is the one you might use for informal stuff but you will want to have an env per project.

I personally like to even have a different env per soft I compile for my own use, except for various go tools such as godeps.

Switching requires for you to use goactivate:

goactivate <envname>

This will set the following variables: * $GOPATH to your env path. * $PATH to include your env /bin folder. * $PS1 to include (envname)$ at the end (this only works if you export your $PS1 which is usually not done)

If the script provided is not suitable for your shell, you can run:

goworkon switch <envname> and that will return a few lines of text containing VARIABLE=value for you to set in your shell.

Knowing what is in your envs.

Finally I added a simple command to list the envs that gives some extra detail, it is (yeah, you guessed)

goworkon list

And the output looks roughly like this:

(1.7.1) "caddy":/home/user/environments/caddy
(1.7.2) "default":/home/user/environments/default
(1.7.2) "goworkon":/home/user/environments/goworkon
(1.7.1) "hugo":/home/user/environments/hugo

In the future they will display more information, but the current format includes:

(goversion) "envname":"env GOPATH"


There are two types of settings in goworkon

Global setings, which for the moment only include the default keyword to choose which is your default env.

The invocation for them is:

goworkon set <variable> <value>

Local settings, which are set per environment and for the moment only include the globalbin key which indicates that the /bin of that environment should always be added into the $PATH which is very useful when, like me, you like to build each soft in one env (also useful when packaging).

The invocation is:

goworkon set <environment>@<variable> <value>

Calling set with a variable and no value will blank it, when the variable is boolean unsetting makes it false and the string "true" makes it true.

What is pending.

There is a stub of the update command that will update the version of go but the rebuilding of the env still is not implemented as it depends on the build-steps feature to be implemented so expect it in the following weeks.

Pseudo Vendoring, I intend to add a freeze command that gives you a file with all the packages currently on your env and the versions that can be used to rebuild it.

Testing I am lacking a lot of testing.

If you have any suggestions dont hesitate to open an issue on github or find me on freenode as perrito666

comments powered by Disqus