7.1 Invoquer guix shell

Le but de guix shell est de faciliter la création d’environnements logiciels à usage unique, sans changer votre profil. Vous l’utiliserez typiquement pour créer des environnement de développement ; c’est aussi une commande pratique pour lancer des applications sans « polluer » votre profil.

Remarque : La commande guix shell a été introduite récemment pour remplacer guix environment (voir Invoquer guix environment). Si vous connaissez déjà guix environment, vous remarquerez qu’elle est similaire mais aussi (on l’espère) plus pratique.

La syntaxe générale est :

guix shell [options] [paquet…]

Sometimes an interactive shell session is not desired. An arbitrary command may be invoked by placing the -- token to separate the command from the rest of the arguments.

L’exemple suivant crée un environnement contenant Python et NumPy, en construisant ou en téléchargeant les paquets manquants et lance la commande python3 dans cet environnement :

guix shell python python-numpy -- python3

Note that it is necessary to include the main python package in this command even if it is already installed into your environment. This is so that the shell environment knows to set PYTHONPATH and other related variables. The shell environment cannot check the previously installed environment, because then it would be non-deterministic. This is true for most libraries: their corresponding language package should be included in the shell invocation.

Remarque : guix shell can be also be used as a script interpreter, also known as shebang. Here is an example self-contained Python script making use of this feature:

#!/usr/bin/env -S guix shell python python-numpy -- python3
import numpy
print("This is numpy", numpy.version.version)

You may pass any guix shell option, but there’s one caveat: the Linux kernel has a limit of 127 bytes on shebang length.

Vous pouvez créer des environnements de développement comme dans l’exemple ci-dessous, qui ouvre un shell interactif contenant toutes les dépendance et les variables d’environnement requises pour travailler sur Inkscape :

guix shell --development inkscape

Sortir du shell vous replacera dans l’environnement de départ, avant d’avoir invoqué la commande guix shell. Au prochain lancement du ramasse-miettes (voir Invoquer guix gc), les paquets installés dans l’environnement et qui ne sont plus utilisés en dehors seront possiblement supprimés.

En plus, guix shell essayera de faire ce que vous espérez quand il est invoqué de manière interactive et sans arguments, comme ceci :

guix shell

S’il trouve un manifest.scm dans le répertoire de travail actuel ou dans l’un de ses parents, il utiliser ce manifeste comme s’il avait été passé avec --manifest. De la même manière, s’il trouve un guix.scm dans ces mêmes répertoire, il l’utilisera pour construire un profil de développement comme si --development et --file étaient présents. Dans tous les cas, le fichier ne sera chargé que s’il réside dans un répertoire listé dans ~/.config/guix/shell-authorized-directories. Cela permet de facilement définir, partager et entrer dans des environnements de développement.

Par défaut, la session shell ou la commande est lancée dans un environnement augmenté, où les nouveaux paquets sont ajoutés aux variables d’environnement de recherche comme PATH. Vous pouvez à la place créer un environnement isolé ne contenant rien d’autre que les paquets que vous avez demandé. Passez l’option --pure pour nettoyer les définitions des variables d’environnement qui se trouvent dans l’environnement parent¹⁴ ; en passant --container vous pouvez aller plus loin en démarrant un conteneur isolé du reste du système :

guix shell --container emacs gcc-toolchain

La commande ci-dessus démarre un shell interactif dans un conteneur avec rien d’autre que emacs, gcc-toolchain et leurs dépendances. Le conteneur n’a pas d’accès au réseau et ne partage pas les fichiers autres que ceux du répertoire de travail avec son environnement. C’est utile pour éviter d’accéder à des ressources systèmes comme /usr/bin sur les distributions externes.

This --container option can also prove useful if you wish to run a security-sensitive application, such as a web browser, in an isolated environment. For example, the command below launches Ungoogled-Chromium in an isolated environment, which:

• shares network access with the host
• inherits host’s environment variables DISPLAY and XAUTHORITY
• has access to host’s authentication records from the XAUTHORITY file
• has no information about host’s current directory

guix shell --container --network --no-cwd ungoogled-chromium \
  --preserve='^XAUTHORITY$' --expose="${XAUTHORITY}" \
  --preserve='^DISPLAY$' -- chromium

guix shell 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"

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

--check

Met en place l’environnement et vérifie si le shell peut écraser les variables d’environnement. C’est une bonne idée d’utiliser cette option la première fois que vous lancez guix shell pour une session interactive pour vous assurer que votre configuration est correcte.

Par exemple, si le shell modifie la variable d’environnement PATH, cela sera rapporté car vous auriez un environnement différent de celui que vous avez demandé.

Ces problèmes indiquent en général que les fichiers de démarrage du shell modifient ces variables d’environnement de manière inattendue. Par exemple, si vous utilisez Bash, assurez-vous que les variables d’environnement sont définie ou modifiées dans ~/.bash_profile et non dans ~/.bashrc — ce premier est sourcé seulement par les shells de connexion. Voir Bash Startup Files dans le manuel de référence de Bash pour plus de détails sur les fichiers de démarrage de Bash.

--development

-D

Fait en sorte que guix shell ajoute à l’environnement les dépendances du paquet suivant au lieu du paquet lui-même. Vous pouvez combiner cette option avec d’autres paquets. Par exemple, la commande suivante démarre un shell interactif contenant les dépendances à la construction de GNU Guile, plus Autoconf, Automake et Libtool :

guix shell -D guile autoconf automake libtool

--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 shell -D -e '(@ (gnu packages maths) petsc-openmpi)'

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

Lancer :

guix shell -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 shell -e '(list (@ (gnu packages bash) bash) "include")'

Voir package->development-manifest, pour apprendre à écrire un fichier manifeste ou l’environnement de développement d’un paquet.

--file=fichier

-f fichier

Crée un environnement contenant 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.69 automake texinfo))))

Avec le fichier ci-dessus, vous pouvez entrer un environnement de développement pour GDB en lançant :

guix shell -D -f gdb-devel.scm

--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 Écrire un manifeste, pour des informations sur l’écriture d’un manifeste. Voir --export-manifest ci-dessous pour apprendre à obtenir un premier manifeste.

--export-manifest

Écrire un manifeste vers la sortie standard utilisable avec --manifest et qui correspond aux options de la ligne de commande données.

C’est une manière de « convertir » les arguments de la ligne de commande en un manifeste. Par exemple, imaginez que vous en ayez marre de taper de longues lignes et souhaitez avoir un manifeste équivalent à cette ligne de commande :

guix shell -D guile git emacs emacs-geiser emacs-geiser-guile

Ajoutez l’option --export-manifest à la ligne de commande ci-dessus :

guix shell --export-manifest \
  -D guile git emacs emacs-geiser emacs-geiser-guile

... et vous obtiendrez un manifeste comme ceci :

(concatenate-manifests
  (list (specifications->manifest
          (list "git"
                "emacs"
                "emacs-geiser"
                "emacs-geiser-guile"))
        (package->development-manifest
          (specification->package "guile"))))

Vous pouvez l’enregistrer dans un fichier, disons manifest.scm, et ensuite le passer à guix shell ou n’importe quelle commande guix :

guix shell -m manifest.scm

Voilà, vous avez convertit une longue ligne de commande en un manifeste ! Ce processus de conversion prend en compte les options de transformation des paquets (voir Options de transformation de paquets) et ne devrait donc pas perdre d’information.

--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 shell --pure --preserve=^SLURM 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 shell 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 shell --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 shell --container --expose=$HOME=/exchange guile -- guile

--symlink=spec

-S spec

Pour les conteneurs, crée le lien symbolique spécifié par la spec, documenté dans pack-symlink-option.

--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.

--nesting

-W

When used with --container, provide Guix inside the container and arrange so that it can interact with the build daemon that runs outside the container. This is useful if you want, within your isolated container, to create other containers, as in this sample session:

$ guix shell -CW coreutils
[env]$ guix shell -C guile -- guile -c '(display "hello!\n")'
hello!
[env]$ exit

The session above starts a container with coreutils programs available in PATH. From there, we spawn guix shell to create a nested container that provides nothing but Guile.

Another example is evaluating a guix.scm file that is untrusted, as shown here:

guix shell -CW -- guix build -f guix.scm

The guix build command as executed above can only access the current directory.

Under the hood, the -W option does several things:

• map the daemon’s socket (by default /var/guix/daemon-socket/socket) inside the container;
• map the whole store (by default /gnu/store) inside the container such that store items made available by nested guix invocations are visible;
• add the currently-used guix command to the profile in the container, such that guix describe returns the same state inside and outside the container;
• share the cache (by default ~/.cache/guix) with the host, to speed up operations such as guix time-machine and guix shell.

--rebuild-cache ¶

La plupart du temps, guix shell met en cache l’environnement pour que les utilisations suivantes soient instantanées. Les entrées du cache utilisées le moins récemment sont régulièrement supprimées. Le cache est aussi invalidé lorsque vous utilisez --file ou --manifest à chaque fois que le fichier correspondant est modifié.

L’option --rebuild-cache force l’environnement en cache à être rafraîchi. C’est utile si vous utilisez les options --file ou --manifest et que les fichiers guix.scm ou manifest.scm ont des dépendances externes, ou si leur comportement dépend, disons, de variables d’environnements.

--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 vous n’utilisez pas cette option, guix shell met en cache les profils pour les utilisations suivantes du même environnement soient immédiates — vous pouvez comparer cela à l’utilisation de --root sauf que guix shell prend soin de régulièrement supprimer les racines du ramasse-miettes utilisées le moins récemment.

Dans certains cas, guix shell ne met pas les profils en cache – p. ex. si des options de transformations comme --with-latest sont utilisées. Dans ce cas, l’environnement n’est protégé du ramasse-miettes que le temps de la session guix shell. 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 en apprendre plus sur les racines du ramasse-miettes.

En plus, guix shell 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).