perri.to: Un méli-mélo de choses

Une balade typique au pays de goworkon

  2016-10-21


Une balade typique au pays de goworkon

Après quelques semaines à travailler dessus et avec lui aussi, j’ai éliminé la plupart des irritants urgents de goworkon.

Alors, maintenant que je me suis débarrassé de ça, je peux faire un petit tour d’horizon de la façon d’utiliser goworkon v0.1alpha1.

Démarrage

Le démarrage est encore un peu cahoteux, mais loin d’être pénible.

En supposant que vous avez installé goworkon (dans mon cas, j’ai simplement utilisé l’un de mes environnements de l’époque et j’ai juste lancé go get -u github.com/perrito666/goworkon et voilà.) vous devrez ajouter quelque chose à votre ~/.bashrc (vous utilisez peut-être un autre shell, je ne peux pas garantir que cela fonctionne là-bas.

La première chose à faire est de sourcer le fichier bash fourni ; dans mon cas c’était simplement :

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

J’ai plutôt utilisé le chemin absolu parce que, pour cela, j’avais retiré ma déclaration de GOPATH du fichier .bashrc.

Cela rendra la commande goactivate disponible dans votre shell. Étant donné que les processus qui s’exécutent dans votre shell ne peuvent pas modifier directement les variables d’environnement, goactivate résout cela en analysant la sortie de goworkon switch et en définissant les variables depuis une fonction bash.

Il y a un peu plus à configurer dans .bashrc, mais nous verrons cela à l’avenir.

Une fois que tout est en place, nous pouvons commencer.

Premier environnement

Lors du premier lancement de goworkon, un $GOROOT fonctionnel vous sera demandé ; c’est nécessaire parce que nous allons compiler go depuis les sources pour chaque nouvelle version et son seul prérequis est un $GOROOT plus récent que 1.4.

Note : Dans les futures versions, cela sera très probablement deviné et le chemin mis à jour à chaque nouvelle installation de go

Pour créer un environnement, nous devons lancer

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

Que se passe-t-il ici ?:

Create effectuera les actions suivantes :

  • Si la version de go n’est pas demandée, la dernière version sera devinée depuis le site de go.
  • Si la version de go n’est pas installée, elle sera téléchargée et compilée.
  • Si envname existe, ce sera un noop.
  • Stocker toutes les données de l’environnement dans ~/.local/share/goworkon/configs/.json, que vous pouvez éditer selon vos besoins, bien que des outils soient fournis pour les parties pertinentes et le seront pour le reste dans les prochaines versions.

Ce que j’ai fait pour ma machine de travail principale, c’est.

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

Le chemin de l’environnement (qui sera le $GOPATH) n’est pas créé tant que vous ne faites pas un go get de quelque chose.

Définir un environnement par défaut

Pour diverses raisons, je garde un environnement « à tout faire » que j’aime avoir toujours défini quand j’entre dans mon shell. Celui-ci s’appelle l’environnement par défaut et vous pouvez choisir n’importe lequel des vôtres.

J’ai choisi default, alors j’ai lancé.

goworkon set default default

Pour faciliter cela, j’ai ajouté à la fin de mon ~/.bashrc ce qui suit :

goactivate default

Ce qui garantit que j’atterris toujours dans mon bash avec default dans le path.

Basculer vers d’autres environnements.

En supposant que vous êtes comme moi, default est celui que vous pourriez utiliser pour des trucs informels, mais vous voudrez avoir un environnement par projet.

Personnellement, j’aime même avoir un environnement différent par logiciel que je compile pour mon propre usage, sauf pour divers outils de go comme godeps.

Basculer nécessite d’utiliser goactivate :

goactivate <envname>

Cela définira les variables suivantes :

  • $GOPATH vers le chemin de votre environnement.
  • $PATH pour inclure le dossier /bin de votre environnement.
  • $PS1 pour inclure (envname)$ à la fin (cela ne fonctionne que si vous exportez votre $PS1, ce qui n’est généralement pas fait)

Si le script fourni ne convient pas à votre shell, vous pouvez lancer :

goworkon switch <envname> et cela renverra quelques lignes de texte contenant VARIABLE=valeur pour que vous les définissiez dans votre shell.

Savoir ce qu’il y a dans vos environnements.

Enfin, j’ai ajouté une commande simple pour lister les environnements qui donne quelques détails supplémentaires, c’est (oui, vous avez deviné)

goworkon list

Et la sortie ressemble à peu près à ceci :

(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

À l’avenir, ils afficheront plus d’informations, mais le format actuel comprend :

(goversion) "envname":"env GOPATH"

Réglages

Il existe deux types de réglages dans goworkon

Réglages globaux, qui pour le moment n’incluent que le mot-clé default pour choisir quel est votre environnement par défaut.

L’invocation pour eux est :

goworkon set <variable> <value>

Réglages locaux, qui sont définis par environnement et pour le moment n’incluent que la clé globalbin, qui indique que le /bin de cet environnement devrait toujours être ajouté au $PATH, ce qui est très utile quand, comme moi, vous aimez compiler chaque logiciel dans un environnement (utile aussi lors de l’empaquetage).

L’invocation est :

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

Appeler set avec une variable et sans valeur la videra ; quand la variable est booléenne, la désactiver la met à false et la chaîne "true" la met à true.

Ce qui reste en attente.

Il y a une ébauche de la commande update qui mettra à jour la version de go, mais la reconstruction de l’environnement n’est toujours pas implémentée car elle dépend de l’implémentation de la fonctionnalité build-steps, alors attendez-vous à cela dans les semaines qui viennent.

Pseudo Vendoring, j’ai l’intention d’ajouter une commande freeze qui vous donne un fichier avec tous les paquets actuellement présents dans votre environnement et les versions qui peuvent être utilisées pour le reconstruire.

Testing, il me manque beaucoup de tests.

Si vous avez des suggestions, n’hésitez pas à ouvrir une issue sur github ou à me trouver sur freenode sous le nom perrito666