8.2 Invoquer guix environment

Le but de guix environment est de vous aider à créer des environnements de développement.

Avertissement d’obsolescence : La commande guix environment est obsolète et remplacée par guix shell, qui effectue les même tâches mais est plus pratique à utiliser. Voir Invoquer guix shell.

Étant obsolète, guix environment sera supprimée à un moment, mais le projet Guix s’engage à la garder jusqu’au premier mai 2023. Contactez-nous sur guix-devel@gnu.org si vous voulez en parler.

La syntaxe générale est :

guix environment options paquet…

L’exemple suivant crée un nouveau shell préparé pour le développement de GNU Guile :

guix environment guile

Si les dépendances requises ne sont pas déjà construites, guix environment les construit automatiquement. L’environnement du nouveau shell est une version améliorée de l’environnement dans lequel guix environment a été lancé. Il contient les chemins de recherche nécessaires à la construction du paquet donné en plus des variables d’environnement existantes. Pour créer un environnement « pur », dans lequel les variables d’environnement de départ ont été nettoyées, utilisez l’option --pure¹⁶.

Sortir d’un environnement Guix est comme sortir du shell, et cela vous replacera dans l’ancien environnement avant d’avoir invoqué la commande guix environment. Au prochain lancement du ramasse-miettes (voir Invoquer guix gc), les paquets installés pour l’environnement seront supprimés et ne seront plus disponibles en dehors de celui-ci.

guix environment définie la variable GUIX_ENVIRONMENT dans le shell qu’il crée ; sa valeur est le nom de fichier du profil de cet environnement. Cela permet aux utilisatrice·eur·s, disons, de définir un prompt spécifique pour les environnement de développement dans leur .bashrc (voir Bash Startup Files dans The GNU Bash Reference Manual) :

if [ -n "$GUIX_ENVIRONMENT" ]
then
    export PS1="\u@\h \w [dev]\$ "
fi

… ou de naviguer dans le profil :

$ ls "$GUIX_ENVIRONMENT/bin"

De surcroît, plus d’un paquet peut être spécifié, auquel cas l’union des entrées des paquets données est utilisée. Par exemple, la commande ci-dessous crée un shell où toutes les dépendances de Guile et Emacs sont disponibles :

guix environment guile emacs

Parfois, une session shell interactive est inutile. On peut invoquer une commande arbitraire en plaçant le jeton -- pour séparer la commande du reste des arguments :

guix environment guile -- make -j4

Dans d’autres situations, il est plus pratique de spécifier la liste des paquets requis dans l’environnement. Par exemple, la commande suivante lance python dans un environnement contenant Python 3 et NumPy :

guix environment --ad-hoc python-numpy python -- python3

En plus, on peut vouloir les dépendance d’un paquet et aussi des paquets supplémentaires qui ne sont pas des dépendances à l’exécution ou à la construction, mais qui sont utiles au développement tout de même. À cause de cela, le tag --ad-hoc est positionnel. Les paquets qui apparaissent avant --ad-hoc sont interprétés comme les paquets dont les dépendances seront ajoutées à l’environnement. Les paquets qui apparaissent après --ad-hoc sont interprétés comme les paquets à ajouter à l’environnement directement. Par exemple, la commande suivante crée un environnement de développement pour Guix avec les paquets Git et strace en plus :

guix environment --pure guix --ad-hoc git strace

Parfois il est souhaitable d’isoler l’environnement le plus possible, pour une pureté et une reproductibilité maximale. En particulier, lorsque vous utilisez Guix sur une distribution hôte qui n’est pas le système Guix, il est souhaitable d’éviter l’accès à /usr/bin et d’autres ressources du système depuis les environnements de développement. Par exemple, la commande suivante crée un REPL Guile dans un « conteneur » où seuls le dépôt et le répertoire de travail actuel sont montés :

guix environment --ad-hoc --container guile -- guile

Remarque : L’option --container requiert Linux-libre 3.19 ou supérieur.

Un autre cas d’usage typique pour les conteneurs est de lancer des applications sensibles à la sécurité, comme un navigateur web. Pour faire fonctionner Eolie, nous devons exposer et partager certains fichiers et répertoires ; nous incluons nss-certs et exposons /etc/ssl/certs/ pour l’authentification HTTPS ; enfin, nous préservons la variable d’environnement DISPLAY puisque les applications graphiques conteneurisées ne s’afficheront pas sans elle.

guix environment --preserve='^DISPLAY$' --container --network \
  --expose=/etc/machine-id \
  --expose=/etc/ssl/certs/ \
  --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
  --ad-hoc eolie nss-certs dbus --  eolie

Les options disponibles sont résumées ci-dessous.

--check

Configure l’environnement et vérifie si le shell écraserait les variables d’environnement. Voir --check, pour plus d’informations.

--root=fichier ¶

-r fichier

Fait de fichier un lien symbolique vers le profil de cet environnement, et l’enregistre comme une racine du ramasse-miettes.

C’est utile si vous souhaitez protéger votre environnement du ramasse-miettes, pour le rendre « persistent ».

Lorsque cette option est omise, l’environnement n’est protégé du ramasse-miettes que le temps de la session guix environment. Cela signifie que la prochaine fois que vous créerez le même environnement, vous pourriez avoir à reconstruire ou télécharger des paquets. Voir Invoquer guix gc, pour plus d’informations sur les racines du GC.

--expression=expr

-e expr

Crée un environnement pour le paquet ou la liste de paquets en lesquels s’évalue expr.

Par exemple, lancer :

guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

démarre un shell avec l’environnement pour cette variante spécifique du paquet PETSc.

Lancer :

guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

démarre un shell où tous les paquets de base du système sont disponibles.

Les commande au-dessus n’utilisent que les sorties par défaut des paquets donnés. Pour choisir d’autres sorties, on peut spécifier des pairs :

guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=fichier

-l fichier

Crée un environnement pour le paquet ou la liste de paquets en lesquels fichier s’évalue.

Par exemple, fichier peut contenir une définition comme celle-ci (voir Définition des paquets) :

(use-modules (guix)
             (gnu packages gdb)
             (gnu packages autotools)
             (gnu packages texinfo))

;; Augment the package definition of GDB with the build tools
;; needed when developing GDB (and which are not needed when
;; simply installing it.)
(package
  (inherit gdb)
  (native-inputs (modify-inputs (package-native-inputs gdb)
                   (prepend autoconf-2.64 automake texinfo))))

--manifest=fichier

-m fichier

Crée un environnement pour les paquets contenus dans l’objet manifeste renvoyé par le code Scheme dans fichier. Vous pouvez répéter cette option plusieurs fois, auquel cas les manifestes sont concaténés.

C’est similaire à l’option de même nom de guix package (voir --manifest) et utilise les même fichiers manifestes.

Voir guix shell --export-manifest, pour des informations sur la « conversion » des options de la ligne de commande en un manifeste.

--ad-hoc

Inclut tous les paquets spécifiés dans l’environnement qui en résulte, comme si un paquet ad hoc était spécifié, avec ces paquets comme entrées. Cette option est utile pour créer un environnement rapidement sans avoir à écrire une expression de paquet contenant les entrées désirées.

Par exemple la commande :

guix environment --ad-hoc guile guile-sdl -- guile

lance guile dans un environnement où Guile et Guile-SDDL sont disponibles.

Remarquez que cet exemple demande implicitement la sortie par défaut de guile et guile-sdl, mais il est possible de demander une sortie spécifique — p. ex. glib:bin demande la sortie bin de glib (voir Des paquets avec plusieurs résultats).

Cette option peut être composée avec le comportement par défaut de guix environment. Les paquets qui apparaissent avant --ad-hoc sont interprétés comme les paquets dont les dépendances seront ajoutées à l’environnement, le comportement par défaut. Les paquets qui apparaissent après --ad-hoc sont interprétés comme les paquets à ajouter à l’environnement directement.

--profile=profil

-p profil

Crée un environnement contenant les paquets installés dans profile. Utilisez guix package (voir Invoquer guix package) pour créer et gérer les profils.

--pure

Réinitialisation des variables d’environnement existantes lors de la construction du nouvel environnement, sauf celles spécifiées avec l’option --preserve. (voir ci-dessous). Cela a pour effet de créer un environnement dans lequel les chemins de recherche ne contiennent que des entrées de paquets.

--preserve=regexp

-E regexp

Lorsque vous utilisez --pure, préserver les variables d’environnement qui correspondent à regexp — en d’autres termes, cela les met en « liste blanche » de variables d’environnement qui doivent être préservées. Cette option peut être répétée plusieurs fois.

guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \
  -- mpirun …

Cet exemple exécute mpirun dans un contexte où les seules variables d’environnement définies sont PATH, les variables d’environnement dont le nom commence par ‘SLURM’, ainsi que les variables « importantes » habituelles (HOME, USER, etc.).

--search-paths

Affiche les définitions des variables d’environnement qui composent l’environnement.

--system=système

-s système

Essaye de construire pour système — p. ex. i686-linux.

--container ¶

-C

Lance commande dans un conteneur isolé. Le répertoire de travail actuel en dehors du conteneur est monté dans le conteneur. En plus, à moins de le changer avec --user, un répertoire personnel fictif est créé pour correspondre à celui de l’utilisateur·rice actuel·le et /etc/passwd est configuré en conséquence.

Le processus de création s’exécute en tant qu’utilisateur·rice actuel·le à l’extérieur du conteneur. À l’intérieur du conteneur, il possède les mêmes UID et GID que l’utilisateur·rice actuel·le, sauf si l’option --user est passée (voir ci-dessous).

--network

-N

Pour les conteneurs, partage l’espace de nom du réseau avec le système hôte. Les conteneurs créés sans cette option n’ont accès qu’à l’interface de boucle locale.

--link-profile

-P

Pour les conteneurs, liez le profil d’environnement à ~/.guix-profile à l’intérieur du conteneur et définissez GUIX_ENVIRONNEMENT à cet endroit. Cela équivaut à faire de ~/.guix-profile un lien symbolique vers le profil réel à l’intérieur du conteneur. La liaison échouera et interrompra l’environnement si le répertoire existe déjà, ce qui sera certainement le cas si guix environment a été invoqué dans le répertoire personnel de l’utilisateur·rice.

Certains paquets sont configurés pour chercher des fichiers de configuration et des données dans ~/.guix-profile ; ¹⁷ ; --link-profile permet à ces programmes de se comporter comme attendu dans l’environnement.

--user=utilisateur

-u utilisateur

Pour les conteneurs, utilise le nom d’utilisateur utilisateur à la place de l’utilisateur actuel. L’entrée générée dans /etc/passwd dans le conteneur contiendra le nom utilisateur ; le répertoire personnel sera /home/utilisateur ; et aucune donnée GECOS ne sera copiée. En plus, l’UID et le GID dans le conteneur seront 1000. user n’a pas besoin d’exister sur le système.

En plus, tous les chemins partagés ou exposés (voir --share et --expose respectivement) dont la cible est dans le répertoire personnel de l’utilisateur·rice seront remontés relativement à /home/USER ; cela comprend le montage automatique du répertoire de travail actuel.

# exposera les chemins comme /home/toto/wd, /home/toto/test et /home/toto/target
cd $HOME/wd
guix environment --container --user=toto \
     --expose=$HOME/test \
     --expose=/tmp/target=$HOME/target

Bien que cela limite la fuite de l’identité de l’utilisateur à travers le chemin du répertoire personnel et des champs de l’utilisateur, ce n’est qu’un composant utile pour une solution d’anonymisation ou de préservation de la vie privée — pas une solution en elle-même.

--no-cwd

Pour les conteneurs, le comportement par défaut est de partager le répertoire de travail actuel avec le conteneur isolé et de passer immédiatement à ce répertoire à l’intérieur du conteneur. Si cela n’est pas souhaitable, --no-cwd fera en sorte que le répertoire de travail courant soit automatiquement partagé not et passera au répertoire personnel de l’utilisateur·rice dans le conteneur à la place. Voir aussi --user.

--expose=source[=cible]

--share=source[=cible]

Pour les conteneurs, --expose (resp. --share) expose le système de fichiers source du système hôte comme un système de fichiers target en lecture seule (resp. en lecture-écriture) dans le conteneur. Si target n’est pas spécifiée, source est utilisé comme point de montage dans le conteneur.

L’exemple ci-dessous crée un REPL Guile dans un conteneur dans lequel le répertoire personnel de l’utilisateur est accessible en lecture-seule via le répertoire /exchange :

guix environment --container --expose=$HOME=/exchange --ad-hoc guile -- guile

--emulate-fhs

-F

Lorsqu’elle est utilisée avec --container, cette option émule une configuration qui respecte le standard de la hiérarchie des systèmes de fichiers (FHS) dans le conteneur, en fournissant /bin, /lib et d’autres répertoires et fichiers spécifiés par le FHS. Comme Guix ne respecte pas les spécifications du FHS, cette option configure le conteneur pour mieux reproduire le comportement des autres distributions GNU/Linux. C’est utile pour reproduire d’autres environnements de développement, tester et utiliser des programmes qui s’attendent à ce que les spécifications du FHS soient suivies. Avec cette option, le conteneur inclura une version de glibc qui lira /etc/ld.so.cache dans le conteneur pour trouver le cache des bibliothèques partagées (au contraire de glibc dans l’utilisation normale de Guix) et configurera les répertoires attendu du FHS : /bin, /etc, /lib, /usr à partir du profil du conteneur.

En plus, guix environment prend en charge toutes les options de construction communes prises en charge par guix build (voir Options de construction communes) et toutes les options de transformation de paquets (voir Options de transformation de paquets).