Gratter la démangeaison
Cette démangeaison particulière était une que j’avais depuis que j’ai quitté python, dans ma vie de développeur précédente, où, en tant que gars de python, j’étais un utilisateur assidu de Virtualenv Wrapper.
Virtualenv, pour ceux qui n’ont pas eu le plaisir, vient résoudre le problème côté utilisateur du vendoring.
Quand on travaille sur plusieurs projets, chacun avec son propre ensemble de dépendances versionnées, on risque de contaminer ses autres projets par l’inclusion de versions différentes de paquets python, ce qui peut devenir vraiment pénible, surtout parce qu’on n’a pas de compilateur pour vous signaler des choses comme « ta signature a changé ».
Comme solution sympa, virtualenv crée un PYTONPATH qui contient les librairies de votre projet et tous les imports de votre projet se font relativement à cela, c’est une solution plutôt sympa.
Les virtualenvs peuvent être « activés » et « désactivés » ; cela provoque le fait qu’un ensemble de variables d’environnement soient définies/supprimées pour faire fonctionner votre interpréteur python relativement à votre path.
VirtualenvWrapper y ajoute une jolie couche de brillance ; au lieu de devoir créer un virtualenv pour chaque projet à un endroit que vous choisissez et de devoir faire un source du script shell activate, virtualenvwrapper vous crée une série de raccourcis qui créent, gèrent et activent les envs pour vous. Cela se fait de manière transparente pour l’utilisateur, vous n’avez jamais vraiment besoin de savoir où les fichiers sont stockés, vous invoquez simplement workon qui bascule pour vous.
Or, Go a un problème similaire ; il n’y a pas de chemin clair sur ce qu’est la bonne solution, il existe des solutions de vendoring comme gb de Dave Cheney qui regroupe tout dans un endroit particulier et vous donne une commande pour envelopper l’utilisation de go qui fait la magie des paths pour vous. Il existe des outils comme godeps de Roger Peppe qui font go get des bons paquets et vérifient la bonne révision guidés par un fichier avec une liste de paquets et de révisions (cela devient plutôt moche quand les dépendances récursives ne correspondent pas).
Aucune des solutions ne convenait à mon flux de travail habituel ; je veux dire, chaque projet peut choisir ce qui convient le mieux à son flux, mais moi, en tant que dev, je veux avoir tous ces projets sur ma machine, sans qu’ils interfèrent, fonctionnels et avec le moins de travail possible.
Ma solution à cela a été GoWorkOn ; j’ai clairement volé le nom de commande de VirtualEnvWrapper, je l’aime vraiment bien.
Ce que fait GoWorkOn est à peu près la même chose que VirtuEnvWrapper : il crée un $GOHOME distinct pour chaque projet et maintient aussi mes binaires go à jour (compilés depuis les releases de code source). Il y a une intégration shell basique que je fournis sous forme de script bash et qui peut être convertie en une fonction déclarée dans votre bashrc pour faciliter son usage (les shells ne permettent pas à un processus en cours d’exécution de modifier leur env, donc le binaire goworkon retourne les incantations d’environnement requises à évaluer dans le shell local).
Avec le temps, il me permettra de mettre à jour ma version de go et de recompiler des projets, et j’ajouterai peut-être un peu plus de sucre élégant bash/shell.
Pour le moment, juste
go get -v github.com/perrito666/goworkon
et vous aurez goworkon prêt dans votre path (il nécessite un go fonctionnel en version >= 1.4).
J’ai ajouté ce qui suit à mon ~/.bashrc pour en faciliter l’usage.
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 : cet article a été créé par un hugo à l’intérieur d’un env goworkon ;)