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
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
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.
When running goworkon for the first time, you will be prompted for a
$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/
.jsonwhich 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:
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:
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)
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