# Guix : un outil pour les remplacer tous :::info Cet article, en cours de rédaction, est placé pour la licence CC BY SA Auteur : Andréas Livet ::: [TOC] ## Introduction Je suis tombé très récemment sur [une dépêche LinuxFR](https://linuxfr.org/news/gnu-guix-version-un-point-zero) annonçant la sortie de la version 1.0 du gestionnaire de paquet [Gnu Guix](https://www.gnu.org/software/guix/) et dans la foulée de la distribution GuixSD et j'ai littéralement pris une claque ! Comme me l'a fait [remarquer quelqu'un dans les commentaire](https://linuxfr.org/news/gnu-guix-version-un-point-zero#comment-1773244), le projet n'est pas tout jeune (7 ans de mémoire), mais c'est passé à travers les mailles de mon filet de veille techno tout ce temps. Je compte bien rattraper le retard car cet outil est tout bonnement hallucinant et je vous invite vraiment à creuser les différentes sources que vous trouverez car, que vous soyez admin sys., devops, développeurs ou simple amateurs de distributions libres, Guix est fait pour vous ! Cette suite d'articles est une tentative, sans doute très imparfaite, de montrer l'ensemble des cas où Guix remplace avantageusement d'autres outils. Vous allez voir, les champs d'applications sont vastes ! Dans l'histoire de l'informatique, des outils/approches, sont venues totalement bouleverser nos manières de voir les choses et de travailler, Guix en fait partie. ## Pourquoi Guix est si génial ? Qu'est ce qui me permet d'avancer que Guix est si important ? Parce que Guix résout un certains nombres de problèmes pour lesquels un nombre impressionnant de solutions de contournement ont été mise au point. Et comment les résout-il ? En traitant le problème à la racine et en proposant une solution *radicale*, rendant les solutions trouvées jusqu'ici obsolète ou du moins inutiles. [Ce long article en anglais](https://ambrevar.xyz/guix-advance/) nous en donne une explication détaillée, mais je vais tâcher de vous résumer ça en quelques paragraphe. _Note : il faut tout de même rappeler que Guix a repris les concepts fondamentaux de [Nix](https://nixos.org/) (et NixOS) tout en utilisant un langage de programmation généraliste (voir plus bas). On pourrait même considérer que Guix est une sorte de fork de Nix tellement qu'ils sont proches._ ### Un gestionnaire de paquet révolutionnaire Guix est avant tout un super gestionnaire de paquet qui règle les principaux problèmes des gestionnaires de paquets classiques. Et oui, tous les linuxiens savent qu'il est difficile de mettre à jour un logiciel qui dépend d'une librairie dans une version différente de celle de sa distribution. ([Cette dépêche LinuxFR](https://linuxfr.org/users/emeric_/journaux/mais-pourquoi-flatpak) résume pas mal la situation actuelle). En effet, vous serez alors obligé de mettre à jour la dépendance pour tous les logiciels installés sur votre distribution et risquez ainsi de casser certains logiciels. Regardez aussi la difficulté que les distributions ont a gérer plusieurs version de certains logiciels en même temps en même temps. Les exemples de ce genre ne manquent pas... Les solutions proposées jusque là était soit : * Le conservatisme : je reste avec mes paquets peu à jour pendant un certain laps de temps entre deux versions de ma distribution (disons entre 6 mois et 3 ans selon les distributions et le degré de stabilité). C'est le choix de la plupart des distributions Linux. * La "rolling release" : je met à jour continuellement les logiciels et les dépendances de mon système tout en courant un risque potentiel de casser quelque chose et d'avoir à le réparer. C'est le choix de distributions comme Gentoo ou encore ArchLinux * Un entre deux : c'est le choix par exemple d'Ubuntu avec les ppa. Il s'agit donc de rajouter des dépôts spécifiques à un paquet (compatible avec sa distribution actuelle) afin de mettre celui-ci à jour. Dans la pratique cela marche plutôt bien mais ça oblige les mainteneur de ppa de créer des paquets pour chaque version d'Ubuntu et donc a une certaine limite. * Avoir un système de "virtualisation de paquet" type flatpak ou snap qui permet de s'abstraire des dépendances du système en embarquant ses propres dépendances soit directement dans l'application qu'on souhaite mettre à jour, soit dans des dépendances communes (pour faire court). * Distribuer les nouvelles versions des logiciels contenant l'ensemble des dépendances. Le meilleur exemple est AppImage. Ça fonctionne bien mais augmente la taille des logiciels et ne permet pas de partager des dépendances donc offre une moins bonne sécurité. Guix résout élégamment l'ensemble de ces problématiques en permettant d'avoir à la fois des logiciels à jours et le partage _optimum_ des dépendances communes. Tout ça en te garantissant que si quelque chose ne fonctionne plus, tu pourra revenir en arrière sans une goutte de sueur ! Je vais tâcher de vous expliquer rapidement comment. * Tous les paquets sont installés dans un dossier `gnu` et sont préfixés d'un hash. De cette manière, il ne peut pas y avoir de collision entre deux versions d'un même paquet. * Si la version d'une dépendance pour un paquet n'est pas précisée, cela prendra la version la plus récente installée sur le système et il est ainsi possible de partager des dépendances entre paquets. * Si jamais un paquet a besoin d'une version spécifique d'une dépendance, il est possible de la préciser, guix la téléchargera au moment de l'installation et le paquet pourra fonctionner sans nuire au fonctionnement du reste du système * Comme guix est un gestionnaire de paquet transactionnel, le système ne peut pas être corrompu lorsqu'une mise à jour n'arrive pas au bout. On a ainsi le meilleur des deux mondes : * La possibilité de mettre à jour un paquet de manière indépendante si celui-ci à besoin de dépendances différentes de celles installées sur le système. * Le partage d'un maximum de dépendances afin de garantir un niveau de sécurité élevé En d'autre mots : il est possible d'être constamment à jour (mode rolling release) tout en ayant une stabilité à celle d'une distribution "conservative". Le tout sans avoir à gérer des dépôts spécifiques comme les ppa. ### Une distribution hackable En plus d'être ce génialissime gestionnaire de paquets, Guix est aussi une distribution Gnu/Linux (le _Gnu_ prend ici tout son sens car c'est une distribution soutenue par le projet Gnu) hautement modifiable. La particularité de cette distribution est qu'elle utilise pour ses fichiers de configuration un langage de programmation fonctionnel nommé [Guile](https://www.gnu.org/software/guile/) qui est une [implémentation libre de Scheme](https://www.gnu.org/software/guile/manual/html_node/Guile-and-Scheme.html), un dérivé de [Lisp](https://fr.wikipedia.org/wiki/Lisp). C'est donc très orienté culture Gnu/Emacs. J'avoue ne pas être un fan d'emacs (ni de vim) et n'y connaître à peu près rien en programmation fonctionnelle. Mais, nous verrons dans les articles suivants que ce n'est pas un frein pour utiliser et bidouiller avec Guix. Cela peut paraître un choix anodin d'utiliser un langage de programmation à la place de fichiers de configurations "statiques" pour une distribution (et même un gestionnaire de paquet), mais en réalité ça change tout. Et oui, là ou avec des [langages dédiés](https://fr.wikipedia.org/wiki/Langage_d%C3%A9di%C3%A9) à un domaine (DSL en anglais), on est toujours limité dans nos possibilités de configuration et par l'apprentissage nécessaire d'une nouvelle syntaxe. Guile devient une sorte de langage universel, extrêmement flexible et permettant des niveaux d'abstractions infinis propre à la programmation. De plus, grâce à des _bindings_ pour les différents logiciel, il est possible de configurer sa machine entièrement en Guile, sans passer directement par les fichiers de configuration de tel ou tel service. En cela, Guix se rapproche d'outils comme [Ansible](https://www.ansible.com/) qui permettent de configurer un système d'exploitation avec une api haut niveau, tout en étant théoriquement plus puissant et flexible du fait de l'utilisation d'un langage de programmation généraliste. ## Domaines d'application Quand je dis que Guix peut remplacer _tous_ les outils, ce n'est pas une métaphore et nous verrons dans les prochains articles des cas pratiques où Guix remplace avantageusement : * Le gestionnaire de paquets de votre distribution. Guix s'installe très facilement sur les principales distributions et cohabite merveilleusement bien avec les autres gestionnaires de paquets. * Le gestionnaire de paquets et de versions de votre langage de programmation. Plus besoin des environnements virtuels pour python, rvm ou bundler pour ruby, npm pour node.js etc. Guix résolve de manière élégante les problématiques à l'origine de la création de tels outils ! * Les technologies de _conteneurisation_ tel que Docker. Nous verrons qu'il est en effet possible de créer des équivalents de conteneurs avec des commandes Guix. * Les gestionnaires de paquets tel que snap ou flatpak, car Guix permet l'installation de plusieurs versions d'un même logiciel et peut aussi limiter les droits d'utilisation d'une application à l'instar de snap ou flatpak. * Les outils d'automatisation de configuration de machine tel que Ansible. * Les outils de création de distribution tel que [Yocto](https://www.yoctoproject.org/) * Et bien entendu, GuixSD peut remplacer votre distribution Linux actuelle ! Bien évidement, tous ces projets ont encore de beaux jours devant eux et sont tous plus avancés et spécifiques que Guix ce qui leur donne une légitimité incontestable. Néanmoins, Guix pourrait théoriquement être utilisé à la place de chacun d'eux, ce que je tâcherai de démontrer dans les articles qui suivront. ## Guix pour remplacer les gestionnaires de paquets Guix étant un gestionnaire de paquet avant tout, il est tout naturel qu'il puisse constituer un remplaçant des autres gestionnaires de paquets existants. Si, comme moi ([ou comme Bryan Lunduke](https://alttube.fr/videos/watch/54f6b95b-8bbc-4b01-ba48-dede84a09014)), vous trouviez qu'il y a déjà trop de fragmentation dans le desktop et qu'il faudrait juste choisir une bonne fois pour toute un format de paquet (par exemple les `.deb`) et un gestionnaire de paquet (par exemple `apt`) et ainsi avoir une compatibilité entre les distros, Guix pourrait être un bon candidat ! En effet, Guix a de nombreux avantages par rapport à ses concurrents : * Il est transactionnel, ce qui signifie que si l'installation des paquets n'aboutie pas pour une raison ou pour une autre (ie coupure d'alimentation), le système n'est pas impacté * Il permet d'avoir plusieurs versions d'un même logiciels installées sur la même machine sans aucun conflit * Il permet d'installer les paquets sans avoir les droits d'administrations (oubliez `sudo`) * Il est possible de revenir, à tout moment, à un état antérieur du système et donc être sûr de retrouver un état fonctionnel si jamais une mise à jour n'a pas fonctionnée. Guix à d'autres avantages, mais déjà ces 4 là le rendent important. ### Guix pour remplacer `apt` Voici par exemple comment je remplace progressivement l'utilisation de `apt` (et `snap`, voir plus bas) sur mon système Xubuntu 18.04. #### Installation Tout d'abord, j'ai installé Guix très facilement en suivant [les instructions et l'installeur officiel](https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html). Ça se résume à : ```bash curl https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh | sudo bash ``` Et à suivre les instructions à l'écran. #### Avant toute choses : gestion des locales Commes les paquets Guix ne sont pas forcément compilés avec la même libc que les paquets de notre système d'exploitation, il faut en premier lieu installer le paquet responsable de la gestion des locales de la libc, comme c'est précisé [dans la doc](https://www.gnu.org/software/guix/manual/en/html_node/Application-Setup.html#Locales) `guix install glibc-locales` Puis rajouter cette variable d'environnement à tous vos fichiers de session (`.bashrc`, `.xsessionrc` etc) : `export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale` Sans cela, vous risquez d'avoir, [comme moi, ce genre de problème](https://issues.guix.info/issue/36180) #### Installation de paquets Après avoir installer guix (voir plus haut). Installer un paquet avec Guix est une opération très simple. J'ai commencé par remplacer certains paquet de ma distribution par des version plus à jour. Par exemple (sans avoir les droits administrateurs): `guix install libreoffice` Qui est un alias de : `guix package -i libreoffice` :::warning **Attention** : La première installation de paquet peut prendre du temps (et de la place !) car Guix va chercher toutes les dépendances nécessaires à toutes les dépendances du paquet vu qu'il ne va utiliser aucunes dépendances installées sur le système. ::: :::info Vous verrez, certains paquets (ou patches) sont même compilés sur votre machine, mais dans l'ensemble, beaucoup de binaires précompilés (appelé substitus) [sont disponibles](https://www.gnu.org/software/guix/packages/) (vois l'atributs "builds" dans la description des paquets). ::: Toutes les dépendances téléchargées se trouvent dans le dossier `/gnu/store`. Voici un petit bout de mon dossier : ``` $ ls --group-directories-first /gnu/store | less 01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15 023gvzf7gqbp61jfpc0674krwv7yiyza-mariadb-10.1.38 02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1 02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1 03bgmiwcr3v5yh6psgh9dvg4qihb7qa0-xdg-desktop-database 03hd5wljl5yirh33czpi738ckq16zyp5-xdg-mime-database 04h27h0myyksngxx8imv416n4iwsiv8m-hunspell-1.7.0 04vqghzmpqzxpd94h1q931xpmazp5s7g-libgc-7.6.6 057dna3nwy84zdvfqss8vbgx1pzkdc2l-libungif-4.1.4 05zlxc7ckwflz56i6hmlngr86pmccam2-pcre-8.42 09x4p4ywz39xzy42kmscfi2nnhwjgybd-curl-7.64.0 0cnnj7kvggda2p12mlmxawz3ni9w5rwa-xcb-util-0.4.0 0fcp0xw1l1r2v42j4kdmn9ra3r7bd45v-gtk-im-modules 0fnyf3043x767xfm6gski5h1576q8wsn-glib-schemas 0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6 0j6sz3bk4chqc8pgfv0fsn6byarwq4df-openldap-2.4.46 0j7xd8b63wv6hfssbacw28bj7rsbx0sk-packages 0ja63438w88gil4lxbpsgc5chmyiqhn6-openldap-2.4.46 0jif6gjzhxcg86q9qb7cjbcxdy8sacsn-python2-pygtk-2.24.0 0k450nckm9yp9vlbykvrb7pqp2njm3c4-libxv-1.0.11 0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3 0r1ihh22jhbii0n3xa4isgscbrynydfr-module-import 0wqgmqnlpr8pzvx4skqdgczym8384fbb-shishi-1.0.2 ``` Comme vous pouvez le voir, toutes les dépendances se trouvent ici. Et dans chaque dépendance se trouve une arborescence propre. Ex : ``` $ tree -d /gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/ /gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/ |-- bin |-- include | `-- libmwaw-0.3 | `-- libmwaw |-- lib | `-- pkgconfig `-- share `-- doc |-- libmwaw | `-- html `-- libmwaw-0.3.15 ``` Se trouve aussi maintenant dans mon répertoire personnel un dossier `.guix-profile` dont voici l'arborescence : ```bash tree -L 1 /home/dede/.guix-profile ~/.guix-profile |-- bin |-- etc |-- include |-- lib |-- libexec |-- manifest |-- sbin -> /gnu/store/8k4pnixpz73kxvxbjqajgbprjjmmgpxy-util-linux-2.32.1/sbin `-- share ``` Le dossier `bin` contient des liens symboliques vers les binaires présents dans `/gnu/store`. On a ainsi un fonctionnement très flexible et je peux choisir très facilement à quel version d'un logiciel attribuer tel ou tel alias. Le fichier qui nous intéresse est `manifest`, il décrit toutes les version des logiciels installés et où ils se trouvent : ```bash (manifest (version 3) (packages (("tree" "1.8.0" "out" "/gnu/store/x5xb40q502s7pnqk9lmsnpc5vpsm1r8r-tree-1.8.0" (propagated-inputs ()) (search-paths ()) (properties)) ("recutils" "1.8" "out" "/gnu/store/wzk023ls4f7dq4mcc3kc86vskhw804n1-recutils-1.8" (propagated-inputs ()) (search-paths ()) (properties)) ("emacs" "26.2" "out" "/gnu/store/b38pn0gnj4jsrf79lg4kr80rn5kaim0q-emacs-26.2" (propagated-inputs ()) (search-paths [...] ``` #### Utilisation des paquets Pour utiliser les paquets installés par Guix, quand on est en ligne de commande, il suffit de rajouter le dossier `bin` à notre `$PATH` : ```bash export PATH="/home/dede/.guix-profile/bin${PATH:+:}$PATH" ``` Pour un usage perein, vous pouvez rajouter cette ligne à votre `.bashrc` si vous utilisez `bash` ou `.zshrc` si vous êtes sous `zsh` : ```bash # Guix # le fichier profile contient l'ajout de `bin` au `$PATH` GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" ``` Maintenant, quand vous tapper par exemple : `libreoffice` C'est la version Guix qui se lance et non plus celle installée sur votre système via apt et cela, sans aucune interference. Si ce n'est les fichiers de configuration qui se trouvent dans votre HOME qui seront partagées (voir plus bas pour le mode bac à sable si vous voulez éviter le partage des fichiers de conf).  _Ici la version 6.1.5.2 de LibreOffice alors que [celle présente dans Xubuntu 18.04](https://packages.ubuntu.com/bionic/libreoffice) est la 6.0.7, le tout sans ppa !_ #### Avec un lanceur graphique Si vous voulez que les lanceurs graphiques (les racourcis dans le menu) lancent directement toutes vos applications Guix, vous n'avez qu'à modifier le fichier `.xsessionrc` en rajoutant la même ligne que dans votre `.bashrc` : ``` # Guix # le fichier profile contient l'ajout de `bin` au `$PATH` GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" ``` Si toutefois vous souhaitez garder vos logiciels installés via `apt` et ne mettre à jour que quelques lanceurs, il est aussi possible de modifier les lanceurs graphique en changeant simplement la commande d'éxecution. Ex avec libreoffice Writer, avant j'avais : `libreoffice --writer %U` Et j'ai simplement mis ça à la place: `/home/dede/.guix-profile/bin/libreoffice --writer %U`  Après m'être assuré que le paquet Guix fonctionnait bien, j'ai pu faire une désinstallation du paquet installé via `apt`. `sudo apt remove libreoffice` Je fais ça petit à petit avec tous les logiciels que j'utilise. Ça me permet en quelque sorte d'avoir une "rolling release" tout en gardant le système auquel je suis habitué. C'est une introduction tout en douceur à Guix :). #### Désinstallation des paquets Il est bien sur possible de désinstaller un paquet très facilement via : ```bash guix remove libreoffice ``` alias de : ```bash guix package -r libreoffice ``` :::info *Note* : Après un remove, guix garde tout de même les fichiers dans `/gnu/store` mais supprime les liens symboliques dans votre `guix-profile`. Pour faire une vraie suppression, il faut faire un `guix gc` qui supprime tous les paquets inutilisées. Mais après quelques tests, certains paquets supprimés restent quand même, je ne sais pas pourquoi. ::: #### Mise à jour des paquets Pour mettre à jour tous les paquets en même temps, il suffit de tapper : `guix upgrade` ou `guix package -u` Si je veux simplement mettre à jour libreoffice par exemple je peux faire : `guix upgrade libreoffice` #### Rechercher un paquet Pour rechercher un paquet, rien de plus simple, exemple avec `libreoffice` : `guix search libreoffice` alias de : `guix package -s libreoffice` Bon, ça renvoit souvent beaucoup de paquets, pas forcément en lien donc on peut simplifier l'affichage avec un grep : `guix search libreoffice | grep -A 2 'name:'` Voir affiner la recherche avec : `guix search libreoffice | grep -A 2 'name: libreoffice'` Après je ne suis pas un pro des petits outils en ligne de commande qui se chaînent (je n'ai que les rudiments) et je suis sûr que des personnes plus douées que moi font des merveilles pour avoir une recherche plus aisée. Bon, je ne vous conseille pas le [site listant les packages Guix](https://guix.gnu.org/packages/), car il est tout bonnement inutilisable. Il ne contient même pas de formulaire de recherche... #### Mettre à jour guix Vous pouvez aisément mettre à jour le logiciel Guix en tappant la commande suivante : `guix pull` Et si vous souhaitez connaître les dernière nouveautés ajoutées, vous pouvez faire un : `guix pull --news` :::info Place dispo avant `guix pull` et juste après un `guix gc` : 6.4Go Place dispo après : 5.5Go Place dispo avant `guix install geary` : 5.5Go. Je ne sais pas pourquoi, il installe mesa et tout avec... et plusieurs versions en plus ! Et cups et autres trucs qui n'ont rien à voir Place dispo après : 3.8Go ::: ### Problèmes rencontrés #### Geary ne se lance pas > [deb] 22:34:06.0860 Gtk: Connecting to session manager [deb] 22:34:06.0861 Gtk: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned [deb] 22:34:06.0889 GLib-GIO: _g_io_module_get_default: Found default implementation keyfile (GKeyfileSettingsBackend) for ‘gsettings-backend’ ![err] 22:34:07.0055 GLib-GIO: Settings schema 'org.gnome.Evolution.DefaultSources' is not installed [1] 1630 trace trap geary #### Pas d'icônes dans simple-scan Pas d'icones dans `simple-scan` : > Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found J'ai essayé un `guix install shared-mime-info` mais sans succès. #### Pas d'entrée de menu pour les applications J'ai install xournal++ mais je n'ai pas d'entrée de menu #### Les paquets ne sont pas à jour J'avais mis à jour guix mais le binaire dans mon espace utilisateur ne pointait pas vers le binaire à jour, faut vraiment faire attention ! #### Pour go `guix install go` fonctionne mais pour l'installation de certains modules j'ai eu une erreur `erreur fatale: linux/errno.h : Aucun fichier ou dossier de ce type` #### Octave Impossibilité de faire du rendu avec Octave ```bash libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast ``` C'est semble-t-il un problème lié à l'usage des drivers proprio... et aucune solution "simple" n'est proposée : https://issues.guix.info/28554 Effectivement, en passant au driver libre (nouveau dans mon cas) ça fonctionne sans problème ! #### Problèmes de certificats SSL avec curl, youtube-dl ou autre Quand je télécharge un fichier en https via curl ou youtube-dl installé via Guix, j'ai une erreur SSL de certificat non présents... ### Guix prend trop de place !! Mon répertoire Guix prend presque 17Go et je n'ai vraiment plus de place disponible sur ma partition système. Le problème c'est que je ne sais pas vraiment comment supprimer un package du store. Le problème c'est que par exemple un : `guix remove go` Télécharge des fichiers !!! Je ne sais pas pourquoi mais guix a besoin de télécharger des paquets pour en supprimer... Et en plus, le remove ne supprime pas vraiment les fichiers, mais les enlève simplement du profile !!! Bon en lisant la doc sur `guix gc` (mais pas sur `guix remove` !) on comprend qu'on ne peut pas vraiment supprimer un paquet avec `guix remove`, qu'on peut seulement le faire avec `guix gc` mais là franchement c'est à n'y rien comprendre. Quand je fais un `guix gc` classique (ou comme il le conseil un `guix gc --delete-generations=1m `) et bah ça supprime tout un tas d'outils nécessaire à Guix ! Il devra donc les retélécharger pour pouvoir faire quoi que ce soit ! Voici ce qu'en dit [la doc](https://guix.gnu.org/manual/en/html_node/Invoking-guix-gc.html) : >Running guix gc with no arguments will collect as much garbage as it can, but that is often inconvenient: you may find yourself having to rebuild or re-download software that is “dead” from the GC viewpoint but that is necessary to build other pieces of software—e.g., the compiler tool chain. De plus, si j'essaie de supprimer directement les stores liées au logiciel dont je n'ai plus besoin. Exemple avec `simple-scan` : ```bash guix gc -D /gnu/store/j1xq4zfc28sd36nb3pyg7kkxnhl29yzs-simple-scan-3.36.0 ``` Guix ne veut pas car il considère que le paquet est encore utilisé ! Du grand n'importe quoi ! Comment un paquet non utilisé peut être considéré comme encore utilisé et des paquets essentiels comme non utilisés... Sérieux, c'est quand même dingue qu'un gestionnaire de paquet rende aussi complexe et incertain la suppression de paquets. Bon en relisant la doc et en essayant de comprendre. Les paquets considérés comme racines ("roots") ne peuvent pas être supprimés. On peut lister toutes les roots ici : `guix gc --list-roots` Et en fait, comme guix garde un historique des paquets installés pour chaque profil utilisateur. Il faut d'abord supprimer l'historique des paquets installés en lançant la commande : `guix package --delete-generations` Et voir que beaucoup ont été supprimées : `guix gc --list-roots` Maintenant je peux enfin vraiment supprimer les logiciels que j'ai désinstaller ! Ouf ! ## Guix pour remplacer les environements de développement Si vous êtes développeurs, vous savez qu'il est nécessaire d'avoir les dépendances spécifiques à un projet accessible depuis ce que l'on appelle souvent un environnement virtuel. En python, on a `virtualenv` et `pyenv`, en ruby `rvm`, en node `nvm` etc. Qui nous permettent de gérer les différentes version de nos langages de programmation. Bien souvent, il y a d'autres outils qui permettent d'installer les dépendances nécessaire à notre projet, soit dans un dossier à part, soit directement dans un dossier `vendor` de notre projet. La encore, chaque langage a ses spécificités, python a `pip` et son système assez simple de dépendances via un simple fichier texte nommé le plus souvent `requirements.txt`, Ruby a `gems` mais à d'autres systèmes plus haut niveau comme `bundle`, Node a bien sûr `npm` (et aussi maintenant `yarn` qui fait la même chose en mieux)et son `package.json` qui fait coulé beaucoup d'encre (enfin surtout le gouffre abyssal qu'est `node_modules`), Php à `composer` et j'en passe et des meilleurs. Bien entendu, tous ces outils n'ont pas les mêmes logiques, ni la même syntaxe de configuration, ni la même efficacité en terme de gestion de performance ou de la place qu'occupe les dépendances sur le disque. Et si une optimisation est réalisé pour un outil, les autres langage n'en bénécifierons pas... Vous vous rendez compte que tous ces langages on passé un temps fou a implémenter les mêmes logiques (parfois avec plus ou moins de brio) simplement pour palier les limitations de nos distributions ? S'il était facile d'avoir plusieurs versions d'un même paquet installer côté à côte dans le système, de pouvoir créer des environnement virtuel (des sessions shell) choissant tel ou tel paquet, on aurait pas besoin de tous ces outils hétérogène ! Grâce à Guix, vous allez pouvoir remplacer tous ces outils par ceux de votre système d'exploitation et cela avec un seul langage ! Articles intéressants : https://trivialfis.github.io/linux/2018/06/10/Using-guix-for-development.html https://dthompson.us/ruby-on-guix.html https://blogs.rdoproject.org/2015/10/guix-tox-a-functional-version-of-tox/ ### Sous python Par exemple, j'ai un projet qui utilise les paquets pip définis dans un fichier `requirements.txt` : ``` lxml==4.3.3 PyYAML==5.1 nose==1.3.7 jinja2-cli==0.7.0 click==7.0 jinja2==2.10 Pillow==6.0.0 ``` Trouver les équivalent Guix des paquets pip via `guix search` Exemple `guix search yaml | grep python` me donne : ```bash name: python2-pyyaml location: gnu/packages/python-xyz.scm:2212:2 name: python-pyyaml location: gnu/packages/python-xyz.scm:2212:2 name: python2-ruamel.yaml dependencies: python2-pytest@3.8.0 name: python2-pyaml dependencies: python2-pyyaml@3.13 python2-unidecode@1.0.23 location: gnu/packages/python-xyz.scm:10184:2 description: pyaml is a PyYAML based python module to produce pretty and name: python-ruamel.yaml dependencies: python-pytest@3.8.0 name: python-pyaml dependencies: python-pyyaml@3.13 python-unidecode@1.0.23 ``` Bon, je ne sais pas pourquoi il y un paquet `python-pyyaml` (avec 2 y) `python-pyaml` mais je pense que le bon est `python-pyyaml`. #### Que faire pour les paquets manquants ? Guix ne contient pas encore tous les paquets `pip` On peut les créer soit même ou par exemple mettre des version à jour. Voici un exemple de module pip que j'ai mis à jour : Voici un autre exemple plus compliqué d'outil python en ligne de commande que j'ai rajouté. Cette procédure est assez mal documentée. Il faut créé un module et le mettre dans une structure de fichier `/gnu/packages` Et ensuite installer le programme avec l'option `-L` : `guix package -L . -i python-jinja2-cli` Sans l'aide des dev sur le canal IRC #guix je n'aurai pas trouvé ! Après je peux accéder à mon exectuable via la ligne de commande : `jinja2` Et je peux bien voir qu'il a été installé via guix : ``` $ guix package -I python-jinja2-cli python-jinja2-cli 0.7.0 out /gnu/store/p3n...-python-jinja2-cli-0.7.0 ``` Et : ``` $ which jinja2 /home/dede/.guix-profile/bin/jinja2 ``` Pour lancer l'environnement de développement avec les paquets locaux il faut aussi utiliser l'option `-L` (je conseil l'option verbosity qui permet d'avoir plus de retours en cas d'erreur): `guix environment -L . --verbosity=2 --manifest=./guix-manifest.scm ` #### Que faire quand sa version n'est pas présente ? #### Comment retrouver son prompt et l'améliorer ? Dans le guide, il précise comment on peut changer son prompt mais j'aimerai récupérer mes anciennes config et juste rajouter un petit truc après. #### Que faire quand on veut importer tout un arbre de dépendance avec des versions spécifiques ? ## Guix pour remplacer les technologies de "contenerisation" https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/ https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-environment.html # Guix pour remplacer une distribution Linux Personnellement, cela fait depuis que j'utilise des distributions linux que j'imagine un tel système.