8.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…]

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

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.

As an added convenience, guix shell will try to do what you mean when it is invoked interactively without any other arguments as in:

guix shell

If it finds a manifest.scm in the current working directory or any of its parents, it uses this manifest as though it was given via --manifest. Likewise, if it finds a guix.scm in the same directories, it uses it to build a development profile as though both --development and --file were present. In either case, the file will only be loaded if the directory it resides in is listed in ~/.config/guix/shell-authorized-directories. This provides an easy way to define, share, and enter development environments.

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.

Cette option --container peut aussi être utile si vous voulez lancer une application sensible en terme de sécurité, comme un navigateur web, dans un environnement isolé. Par exemple, la commande suivante lance Ungoogled-Chromium dans un environnement isolé, cette fois en partageant l’accès réseau de l’hôte et en préservant sa variable d’environnement DISPLAY, mais sans partager même le répertoire actuel :

guix shell --container --network --no-cwd ungoogled-chromium \
  --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, for information on how to write a manifest for the development environment of a package.

--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.64 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, for information on how to write a manifest. See --export-manifest below on how to obtain a first manifest.

--export-manifest

Write to standard output a manifest suitable for --manifest corresponding to given command-line options.

This is a way to “convert” command-line arguments into a manifest. For example, imagine you are tired of typing long lines and would like to get a manifest equivalent to this command line:

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

Just add --export-manifest to the command line above:

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

... and you get a manifest along these lines:

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

You can store it into a file, say manifest.scm, and from there pass it to guix shell or indeed pretty much any guix command:

guix shell -m manifest.scm

Voilà, you’ve converted a long command line into a manifest! That conversion process honors package transformation options (voir Options de transformation de paquets) so it should be lossless.

--profile=profil

-p profil

Create an environment containing the packages installed in profile. Use guix package (voir Invoquer guix package) to create and manage profiles.

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

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

The --rebuild-cache forces the cached environment to be refreshed. This is useful when using --file or --manifest and the guix.scm or manifest.scm file has external dependencies, or if its behavior depends, say, on environment variables.

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

When this option is omitted, guix shell caches profiles so that subsequent uses of the same environment are instantaneous—this is comparable to using --root except that guix shell takes care of periodically removing the least-recently used garbage collector roots.

In some cases, guix shell does not cache profiles—e.g., if transformation options such as --with-latest are used. In those cases, the environment is protected from garbage collection only for the duration of the guix shell session. This means that next time you recreate the same environment, you could have to rebuild or re-download packages.

Voir Invoquer guix gc, for more on GC roots.

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