Scratching the itch
This particular itch, was one that I had since I left python, in my previous developer life, as a python guy, I was an avid user of Virtualenv Wrapper.
Virtualenv, for those who didn’t have the pleasure, comes to solve the user-side problem of vendoring.
When working on multiple projects, each with its own set of version dependencies, you risk tainting your other projects with the inclusion of different versions of python packages, this can be really nasty, especially since you dont have a compiler to tell you things like “your signature changed”.
As a cool solution, virtualenv creates a PYTONPATH that holds libraries for your project and all the importing in your project is done relative to that, its quite a cool solution.
Virtualenvs can be “activated” and “deactivated” this causes a set of environment variables to be set/unset to make your python interpreter work relative to your path.
VirtualenvWrapper adds a nice coat of shiny on top of this, instead of having to create a virtualenv for each project in a place you choose and having to source the activate shell script for it, virtualenvwrapper will create for you a series of shortcuts that create, manage and activate envs for you. This is done in a transparent manner to the user, you never really have to know where the files are stored, you just invoke workon which will switch for you.
Now, Go has a similar issue, there is no clear path on what is the right solution, there are vendoring solutions like gb by Dave Cheney that bundles everything into a particular place and gives you a command to wrap the usage of go that will do the path magic for you. There are tools like godeps by Roger Peppe that will go get the right packages and check the right revision guided by a file with a list of packages and revisions (becomes quite ugly when recursive dependencies dont match).
None of the solutions where ok with my regular workflow, I mean each project can choose whatever fits better their workflow but me, as a dev, want to have all these projects in my machine, not interfering, working and with the least possible work.
My solution to this was GoWorkOn I clearly stole VirtualEnvWrapper’s command name, I really like it.
What GoWorkOn does is pretty much the same as VirtuEnvWrapper, it creates separate $GOHOME for each project and also maintains my go binaries up to date (compiled from source releases). There is a basic shell integration that I provide as a bash script and that can be converted into a function declared in your bashrc to facilitate its usage (shells wont allow a running process to change their env so goworkon binary returns the required environment incantations to be evaluated in the local shell).
With time it will allow me to update my go version and rebuild projects and I might add some more elegant bash/shell sugar.
For the moment just
go get -v github.com/perrito666/goworkon
and you will have goworkon read in your path (it requires a working go in version >= 1.4).
I added the following to my ~/.bashrc to make its usage easier.
function goactivate {
GOWORKONEVVARS=$(goworkon switch $@)
if [ $? -eq 0 ]; then
while read -r oneenvvar; do
eval "export $oneenvvar"
done <<< "$GOWORKONEVVARS"
else
echo "cant switch to $@"
fi
}PS: this post was created by a hugo inside a goworkon env ;)