Rascando la comez贸n
Esta comez贸n en particular era una que ten铆a desde que dej茅 python, en mi vida previa como desarrollador, cuando, como tipo de python, era un 谩vido usuario de Virtualenv Wrapper.
Virtualenv, para quienes no tuvieron el placer, viene a resolver el problema del lado del usuario del vendoring.
Cuando trabaj谩s en m煤ltiples proyectos, cada uno con su propio conjunto de dependencias con versiones, corr茅s el riesgo de contaminar tus otros proyectos con la inclusi贸n de versiones distintas de paquetes de python, lo que puede ponerse muy feo, especialmente porque no ten茅s un compilador que te avise cosas como “tu firma cambi贸”.
Como soluci贸n copada, virtualenv crea un PYTONPATH que contiene las librer铆as de tu proyecto y todo el importado en tu proyecto se hace relativo a eso; es una soluci贸n bastante copada.
Los virtualenvs pueden “activarse” y “desactivarse”; esto hace que se seteen/desseteen un conjunto de variables de entorno para que tu int茅rprete de python funcione relativo a tu path.
VirtualenvWrapper le agrega una linda capa de brillo por encima; en vez de tener que crear un virtualenv para cada proyecto en un lugar que elijas y tener que hacer source del script de shell activate, virtualenvwrapper te crea una serie de atajos que crean, gestionan y activan envs por vos. Esto se hace de manera transparente para el usuario, nunca ten茅s que saber realmente d贸nde se guardan los archivos, simplemente invoc谩s workon, que cambia por vos.
Ahora bien, Go tiene un problema similar; no hay un camino claro sobre cu谩l es la soluci贸n correcta, hay soluciones de vendoring como gb de Dave Cheney que empaqueta todo en un lugar particular y te da un comando para envolver el uso de go que hace la magia de paths por vos. Hay herramientas como godeps de Roger Peppe que hacen go get de los paquetes correctos y verifican la revisi贸n correcta guiadas por un archivo con una lista de paquetes y revisiones (se pone bastante feo cuando las dependencias recursivas no coinciden).
Ninguna de las soluciones se llevaba bien con mi flujo de trabajo habitual; digo, cada proyecto puede elegir lo que mejor se adapte a su flujo, pero yo, como dev, quiero tener todos estos proyectos en mi m谩quina, sin que interfieran, funcionando y con la menor cantidad de trabajo posible.
Mi soluci贸n para esto fue GoWorkOn; claramente le rob茅 el nombre del comando a VirtualEnvWrapper, me gusta mucho.
Lo que hace GoWorkOn es pr谩cticamente lo mismo que VirtuEnvWrapper: crea un $GOHOME separado para cada proyecto y adem谩s mantiene mis binarios de go actualizados (compilados desde los releases de c贸digo fuente). Hay una integraci贸n b谩sica de shell que provisiono como un script de bash y que puede convertirse en una funci贸n declarada en tu bashrc para facilitar su uso (los shells no dejan que un proceso en ejecuci贸n cambie su entorno, as铆 que el binario goworkon devuelve los conjuros de entorno requeridos para ser evaluados en el shell local).
Con el tiempo me permitir谩 actualizar mi versi贸n de go y recompilar proyectos, y quiz谩s agregue algo m谩s de az煤car elegante de bash/shell.
Por el momento, solo
go get -v github.com/perrito666/goworkon
y vas a tener goworkon listo en tu path (requiere un go funcionando en versi贸n >= 1.4).
Agregu茅 lo siguiente a mi ~/.bashrc para facilitar su uso.
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
}PD: este post fue creado por un hugo dentro de un env de goworkon ;)