zimoun a écrit 70 commentaires

Guix/nix font probablement toutes ces choses mieux (l'inverse serais dommage), ils ne les ont pas forcément inventé et les gens n'ont pas attendu nix pour proposer des solutions

Oui tout à fait. D'ailleurs, les principes de Nix ont été posés dans une thèse et on sait tous qu'une thèse c'est beaucoup d'existant et un soupcon de nouveauté/originalité. ;-)

https://nixos.org/~eelco/pubs/phd-thesis.pdf

apt-build permet de reconstruire un paquet très facilement et le comparer avec l'existant n'est pas très compliqué

Merci pour l'information.

Comment est contrôlé la chaine de compilation ?

Un journal précédent posait d'ailleurs il me semble la question du nettoyage automatique, qui était inefficace, contrairement aux mécanismes plus classiques. Certes, ça n'impacte que les machines avec un espace disque restreint, mais bon, sur ma machine a moi, j'ai moins de 300Gio de disque (c'est un ssd pas tout neuf, certes), et ça me ferait chier que chaque distro dessus ait besoin de plus de 30Gio d'espace disque pour /.

Si par nettoyage automatique on parle de guix gc, je ne sais pas si on peut dire inefficace. Même si oui il y a des choses à améliorer.

https://guix.gnu.org/manual/en/html_node/Invoking-guix-gc.html#Invoking-guix-gc

En fait, on peut conserver qu'un certain nombre de générations (disons 3) ce qui permet de faire au plus 3 roll-backs.

En espace limité, il y a les manifests qui permettent de ne stocker que des fichiers textes pour restaurer ultérieurement un état précis. Mais sans garanti que les binaires seront encore disponibles donc peut-être la CPU sera un peu mangé par quelques compilations. :-)

Quelque part, c'est "no free lunch". ;-)

Toujours est-il que ce serait intéressant de regarder l'espace disque occupé par une distro classique versus la taille de /gnu/store ne conservant que 2 ou 3 générations.

DPKG (nope, APT n'est pas un gestionnaire de paquets, il se contente de télécharger un paquet et ses dépendances) est majoritairement "déclaratif" c'est à dire basé sur un simple fichier de configuration.

Peut-être que je comprends mal ce qu'est APT. J'avais cru comprendre que c'était Advanced Packaging Tools donc une suite d'outils pour manipuler les paquets Debian. D'après ma compréhension, dpkg est un outil qui gére à proprement parler le .deb mais il ne gère pas la résolution de conflit qui est faite par apt ou aptitude, non ?

C'était des gros guillemets parce que l'analogie ne vaut qu'une analogie. :-)

Debian se comporte de manière procédurale (état séquentiel) et mutable. Par exemple, tu n'as aucune garantie que la séquence apt update, apt install foo, apt remove bar donne le même état final que apt update, apt remove bar, apt install foo.

Dans Guix, le résultat sera le même. Enfin normalement. ;-)

Pour le dire autrement, dans Debian, il y a des effets de bord qui sont contrôlés dans un style impératif. Dans Guix, les effets de bord sont contrôlés dans un style fonctionnel.

https://guix.gnu.org/manual/en/html_node/The-Store-Monad.html#The-Store-Monad

À noter qu'au taf, j'ai opté pour la création de paquets qui activent les services qu'on écrit,

Concernant les services, c'est presque la même histoire que pour les paquets. ;-)

Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?

Tout dépend de si GCC 7 et GCC 8 ont la même ABI. Si c'est pas le cas, c'est en effet le job de distro de gérer.
Mais bon, hé, vraiment, mauvais exemple ici (a moins que tu aies un bug causé par une incompat entre ces compilos?),

Considérons ceci :

#include <stdio.h>

int main() {
    printf("Bonjour\n");
    return 1;
}

Et compilons avec GCC 6 et GCC 7 :

gcc-6 hello.c -o hello-6
gcc-7 hello.c -o hello-7

Evidemment ./hello-6 et ./hello-7 produisent la même sortie. Mais ce ne sont pas les mêmes binaires :

md5sum hello-{6,7}
e1c353671a5c2737e819cf586503865c  hello-6
608d3e055a4f7eb124ebc43747152fd7  hello-7

Doit-on considérer que le même code source compilé par 2 compilateurs est la même version ou non ? Qu'est-ce qu'une même version ? Code source identique ? Binaire identique ? Résultat identique ?

Et là commence les ennuis. ;-) Parce que GCC 6 est lui même un binaire donc produit par un autre binaire.

C'est le problème du yahourt. Pour produire un yahourt (binaire), il faut un yahourt (compilateur) et du lait (source). Et donc quel est le yahourt initial ? Et si ce yahourt initial change, va-t-on produire le même yahourt final ?

Ce n'est pas un problème d'ABI. C'est un problème de qu'est-ce qui définit la version d'un logiciel ? Une fois définie, on peut parler de même version ou version différente.

Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet.

L'équivalent d'un méta-paquet qui dépend au choix d'un ou plusieurs paquets, ou l'équivalent d'un paquet qui fournit un paquet virtuel? Non, parce que bon, Debian implémente ça depuis que je m'en sers, soit au moins 10 ans.

Ce n'est pas un méta-paquet. Du moins de ce que je comprends.

Un méta-paquet permet de résoudre un problème de nommage ou il permet d'installer une collection de paquets.

Un paquet utilisant inherit utilise la recette du paquet qu'il hérite et la modifie.

Par exemple

• la définition longue de GnuPG (v2.2.19)

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n247

• GnuPG v2.0.30 l'utilise et change des choses

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n320

• et GnuPG v1 l'utilise aussi

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnupg.scm#n366

Les 3 paquets sont fonctionnels en soi. Il n'y a pas de "coquilles vides". C'est juste que la définition du paquet gnupg-2 hérite de la définition du paquet gnupg.

J'ai peut-être mal compris ce qu'était un méta-paquet.

Toujours est-il que Guix utilise plein de choses existantes ailleurs. Une partie de l'originalité est de les rassembler de manière cohérente.

Du coup, je suis curieux, tu fais comment pour rollback une install d'un .deb qui foire?

Debian n'est pas transactionnel à ma connaissance (très limitée). Donc si ca foire au milieu, c'est un peu le début de la galère. Enfin cela dépend ce qui a foiré etc.

Pour du roll-back, toujours à ma connaissance très partielle, la solution c'est le snapshot. Soit tu snapshotes niveau système de fichiers, soit tu utilises snapshot.debian.org en connaissant les dates etc.

Dans tous les cas, c'est ce que j'appelle "un peu de d'habitude quand même". ;-)

Le repro-build, c'est en cours pour Debian

Oui le repro-build est bien avancé dans Debian. Cependant, toujours à ma connaissance, le paquet peut être reproductible, mais tu n'as aucune garantie que le binaire que tu tires a bien été compilé en utilisant la recette de construction qui a été testée. Tu peux juste avoir la garantie que le binaire a été poussé par une personne de confiance (via les signatures etc.).

Je ne connais pas les outils Debian mais dans Guix, tu peux faire:

guix build foo                        #1
guix build foo --check --no-grafts -K #2

L'étape #1 va mettre ce qu'il faut dans /gnu/store/ en utilisant les substituts s'ils sont disponibles, donc cela va télécharger un tas de binaires.

L'étape #2 va reconstruire le paquet en local et dire si le résultat (hash) est le même que cela qui a été téléchargé. Si ce hash n'est pas le même, cela signifie que le paquet n'est pas reproductible. Soit le substitut a été corrompu, soit il y a une cause de non-reproducibilité dans le code et là il faut sortir diffoscope (initier par Debian à ma connaissance) et chercher la cause.

http://snapshot.debian.org/

Merci. Même si je connaissais, c'est mieux d'être précis. :-)

Il faut les droits administrateurs—ceci est un détail mais peu vite devenir fastidieux suivant l'environnement dans lequel on travaille (cluster partagé).

Ensuite, il faut donc modifier le fichier sources.list pour ajouter les dépôts à tirer, faire apt update et ensuite apt install foo installera la version que l'on souhaite. Version qui peut être en conflit avec une version de foo déjà installée, ou pire avec une des dépendances de foo, ou des dépendances de dépendances. Et cela peut vite devenir l'enfer. (Sauf à recourir à un outil externe à Debian comme Docker. ;-))

L'équivalent de cette procédure avec Guix serait : guix pull --commit=12345abcdef puis guix install foo --profile=good-old-foo et il n'y a pas de question sur de possibles conflits.

La commande time-machine permet de faire beaucoup mieux car dans Guix il y a un concept qui permet d'avoir plusieurs versions de Guix (index des paquets) sans conflits : inferior.

https://guix.gnu.org/manual/en/html_node/Inferiors.html#Inferiors

Chose à ma connaissance difficile avec Debian et APT.

Donc par exemple, je peux vouloir utiliser foo une seule fois dans sa vielle version. Dans ce cas :

$ guix time-machine --commit=12345abcdef     \
    -- environment  --container --ad-hoc foo \
    -- foo

récupéra la bonne version de l'index des paquets, puis construira ce qu'il manque et lancera foo dans un conteneur (pour éviter une faille de sécurité par exemple).

Pour finir, la dernière chose qui n'a pas été évoqué est la bootstrappabilité. Pour le dire clairement, comment est construit / compilé le compilateur utilisé pour compiler la version de foo du 14 juillet 2017 ?

Dans la machinerie des snapshots, je ne sais pas si les choses sont aussi transparentes, binairement parlant. Et donc à ma connaissance, les binaires sont conservés car ils sont difficiles—si ce n'est impossible—à reproduire bit-à-bit.

Passer du canal stable au canal unstable, ça correspond à un dist-upgrade sous Debian. Ca fait
longtemps que je n'ai pas fait de dist-upgrade mais je ne crois pas que ça se fasse en 5 min.

Quand tu le fais sur l'installation minimal, si, une debian, ça prend deux minutes.

Non, concernant Debian, d'un point de vue théorique cela dépend de la divergence entre la branche stable de la branche unstable.

D'un point de vue pragmatique, cela peut déjà prendre 2 minutes pour mettre à jour avec apt update. Et ensuite le temps de apt upgrade dépendra fortement de votre réseau et du réseau d'où les binaires sont tirés.

Je ne connais pas Nix et uniquement un peu Guix.

Perso, le journal sur GUIX m'a fait joué avec l'original (NixOS) ce week end. Sur le papier ça semble bien, j'aime bien l'idée de la recette de cuisine à la puppet (même si très voir trop basique en comparaison de Puppet/Ansible & co).

Je n'ai jamais utilisé Puppet/Ansible & co..

Dans Guix, il y a guix deploy qui fait pas mal de boulot. Alors j'aimerais bien savoir ce qui est trop basique, i.e., ce que fait Pupper/Ansible & co. que ne ferait pas guix deploy.

https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-deploy.html

Mais par contre, c'est d'une lenteur pour installer des paquets! Le passage de stable vers unstable a mis trois plombe

Dans Guix, il n'y a pas de notion de stable vs instable. Donc je ne comprends pas cette phrase.

Une fois le gestionnaire de paquet installé, il faut faire un premier guix pull qui est l'équivalent d'un apt update. Est-ce cette étape qui vous a paru longue ?

Ensuite pour installer un paquet (avant ou après guix pull peu importe), est-ce la commande guix install foo qui vous a paru longue ? Si oui, quel était le paquet foo en question ?

et mon sentiment général que que NixOS, c'est l'inverse d'ArchLinux, ne gardons rien de simple!

Hum? c'est étrange comme remarque… Sans troller, aujourd'hui les utilisateurs de Guix System sont souvent principalement des anciens utilisateurs de ArchLinux, Gentoo ou Debian, même si je n'ai pas vraiment de chiffres pour affirmer cela. :-)

Toujours est-il que le gros avantage de Guix (gestionnaire de paquets), c'est que cela peut s'installer sur n'importe quelle distro. Donc on peut allier le meilleur des mondes. ;-)

salut roptat :-)

Oui tout à fait ! On peut se coordonner pour écrire la suite. :-)

J'en profite pour aussi dire qu'il y a un manuel en francais

https://guix.gnu.org/manual/fr/html_node/

et qu'un bon moyen de se mettre le pied à l'étrier est de rapporter les erreurs/coquilles et/ou traduire ce qu'il manque. ;-)

• La connaissance de Scheme n'est pas nécessaire dans un premier temps.
• (La (connaissance (des (parenthèses)))) est nécessaire dans un deuxième temps.
• Pour bricoler en expert, il faudra apprendre un peu de Scheme.

La première chose est d'installer Guix sur ta distribution actuelle. Il n'y aura pas de conflit et cela permet de tester et comprendre un peu les concepts. Juste avec la gestion de paquets. (Avant d'aller plus loin avec les services, une autre histoire ;-))

Il faut commencer par les profiles, le côté rolling release et pull en particulier les channels et describe, aussi les environments.

Ensuite, il faut passer par les manifests pour déclarer ses profils. C'est là qu'il faut commencer à taper des parenthèses. Mais pas vraiment du Scheme. Juste un DSL avec des parenthèses.

Ensuite, une étape passe par créer ses paquets. Un peu plus Scheme mais pas vraiment non plus. Il faut voir cela comme un DSL avec des parenthèses.

Jusque là, tout se fait avec la CLI. Et cette CLI a une interface Emacs.

https://emacs-guix.gitlab.io/website/

On peut s'arrêter là, même pour une utilisation avancée dans la gestion des paquets.

L'étape suivante serait de jouer avec guix repl qui lance un Read-Eval-Parse-Loop. Cela permet de manipuler les paquets avec du code, écrire des petites fonctions etc. Et c'est à cette étape là qu'il faut commencer à écrire du Scheme. Mais bon, la plupart des choses usuelles se font en ligne de commande ; comme pour les autres gestionnaires de paquets.

A titre d'analogie, ce n'est pas parce que l'on ne sait pas écrire des scripts fu que l'on ne peut pas utiliser Gimp. Ou du Lisp et AutoCAD. Ben là, c'est un peu pareil. Guix vient avec le concept de hackabilité ; pour les experts en quelque sorte. Mais ce n'est pas nécessaire pour une utilisation quotidienne et même avancée.

Pour le dire autrement, il ne faut pas connaître les subtilités du dossier debian/, ni le C++ pour utiliser Debian et faire apt install ou apt update. De la même manière, il ne faut pas connaître Scheme pour utiliser Guix.

Il y a un intérêt à changer les choix de Debian pour tout ton système, pas d'intérêt d'avoir 3 fois la même version d'une librairie.

Peut-être que pour toi ça n'a pas d'intérêt mais perso j'utilise cette fonctionnalité tous les jours.

Toute la question est la définition de même version. Comme je demandais, est-ce que, considérant toutes les autres options exactement les mêmes,libfoo-1.2.3 compilée avec GCC 7 est-elle la même version que celle compilée avec GCC 8 ?

D'ailleurs, je pense que NixOS ne permet pas directement ce que tu indiques : 3 compilations différentes d'une même version de libraire pour 3 logiciels consommateurs différents.

C'est expliqué ici pour nix : https://nokomprendo.gitlab.io/posts/tuto_fonctionnel_20/2018-04-28-README.html . Tu peux compiler autant de versions que tu veux, choisir les dépendances, le compilateur, les options de cmake, etc.

Ceci est vrai dans une certaine mesure. Je ne connais pas Nix mais Guix définit différents inputs et il est facile de changer les explicit inputs, en utilisant les transformations de build.

En revanche, dans Guix il n'est pas facile de ré-écrire les implicit inputs.

Disons pour schématiser, libfoo-1.2.3 dépend de bax (explicit) et bar (explicit) puis bar dépend de baz (implicit) puis baz dépend de baf (implicit) qui dépend de bax (implicit).

Il est facile de changer comment libfoo-1.2.3 est compilée.

Il est facile de changer la version ou même la bibliothèque bar elle-même, par exemple guix build foo --with-inputs=bar=café.

Mais, guix build foo --with-inputs=bax=pax ne changera pas comme baf a été compilé et n'utilisera pas pax à la place de bax dans la compilation de baf. Il faut ré-écrire "manuellement" un nouveau paquet de baf disons giffle avec la dépendance à pax, ré-écrire un nouveau paquet baz disons taz et aussi un nouveau bar disons troquet.

Bref, tout est possible et tout dépend de ce que l'on appelle même et différent. Le gros avantage, c'est que Guix donne les outils pour manipuler le graphe des dépendances et surtout détecter que l'on fait bien les choses que l'on veut faire. :-)

Je ne connais pas NixOS, uniquement un petit peu Guix.

La première chose est que Guix signifie :

• une gestionnaire de paquets
• une distribution utilisant ce gestionnaire de paquets

Vous pouvez utiliser le gestionnaire de paquets sur n'importe quelle distribution GNU/Linux et il n'y aura aucun conflit. Et pour le déinstaller, il suffit de faire guix package --list-profiles pour faire le ménage dans les liens symboliques, quelques autres petites choses dans le cache e.g., ~/.cache/guix puis simplement rm -fr /gnu/ /var/guix.

La deuxième chose est que Guix (originellement Nix) est un changement de paradigme. Un gestionnaire de paquets comme APT peut être vu comme "impératif" tandis que Guix comme "fonctionnel". Tout ca avec des très gros guillemets ! :-) Alors il y a choses que se font facilement avec l'un et difficilement avec l'autre, et vice-versa.

---

Concrètement, que signifie 3 fois la même version ? Est-ce que la version libfoo-1.2.3 compilé par GCC 7 ou GCC 8 ou autre signifie la même version pour vous ?

Pour finir, que signifie pour vous 3 compilations différentes d'une même version pour 3 logiciels consommateurs différents ?

Par exemple, Guix a la notion de "transformations" de paquet qui permet dans une certaine mesure de ré-écrire le graphe des dépendances. Cette entrée pourrait vous intéresser :
https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/

Par ailleurs, Guix a aussi la notion d'héritage (inherit) pour un paquet. Donc vous pouvez prendre la bibliothèque libfoo-1.2.3 avec ses options de compilations et les changer, et uniquement elles.

En revanche, il n'est pas possible aujourd'hui de "propager" ces options de compilations, un peu comme le fait Gentoo avec USER flag. Mais il y a des discussions récentes pour savoir qu'est-ce qu'il serait souhaitable. Voir tout le thread là :
https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00026.html

En terme de gestion de paquets, le paradigme de Guix vient avec :

• coexistence de différents outils incompatibles entre eux : profile et environment
• générations / transactions : roll-back
• configuration déclarative : fichier manifest
• voyage dans le temps : time-machine

Autant les 3 premiers points peuvent être obtenus avec des gestionnaires de paquets "classiques" modulo un peu de d'habitude quand même, autant le voyage dans le temps est impossible—à ma connaissance. Aujourd'hui, il est impossible de restaurer (recompiler) une version de l'archive (par exemple Debian, je ne connais pas assez Arch ou autres) telle qu'elle était exactement disons le 14 juillet 2017.

Et donc Guix peut générer des conteneurs (Docker, Singularity, tarball) de manière reproductible (en s'affranchissant du paramètre : quand l'image a-t-elle été générée ?) en ne conservant qu'un simple fichier texte (manifest).

Quelques pointeurs à cliquer :

https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
https://guix.gnu.org/manual/en/html_node/Features.html#Features
https://guix.gnu.org/manual/en/html_node/Invoking-guix-pull.html#Invoking-guix-pull
https://guix.gnu.org/manual/en/html_node/Invoking-guix-time_002dmachine.html#Invoking-guix-time_002dmachine
https://guix.gnu.org/blog/2020/reproducible-computations-with-guix/

Et pour le coup, d'ailleurs, je suis toujours pas sûr des différences

Il y a suffisamment de différence pour que les gens de chez Nix aient empaqueté flatpack ;-)
Voir cette page.

Et GNU Guix hérite des concepts de Nix avec une implémentation différente et parfois d'autres choix techniques.

Pour info, je veux pas avoir l'air de faire mon lourd à toujours vous comparer avec flatpak. C'est simplement que c'est le seul aussi système de paquet/conteneur que je connais bien. Donc j'essaie juste de comprendre les différences entre guix et flatpak parce que je connais pas grand chose d'autre dans cette catégorie.

Je fais les mêmes remarques que roptat formulées un peu différemment. En espérant que cela aide à mieux cerner les différences. Sachant que je ne suis pas un utilisateur de flatpack.

---

Pour faire simple, flatpack construit sur un runtime/SDK et donc quel est le contrôle sur cela ? Quelle est la version du compilateur C ? Comment cela a-t-il été bootstrappé ?

Liens bootstrap: dans Guix ou généralement pour le C ou l'effort pour Rust.

Si je comprends bien, avec les lignes 4-6 de org.gimp.GIMP.json un environnement est tiré qui contient un certain nombre de binaires. Est-ce que dans disons 2 ans, si cet environnement n'est plus disponible en ligne, sera-t-on capable de le reconstruire à l'identique (bit-to-bit) ?

Si on considère un dockerfile (finalement très similaire à flatpack me semble-t-il), ce fichier/recette utilise disons une image Debian stable, et depuis le 22 juillet 2017, il y a eu 9 mises à jour mineures de la version stable, dont 3 "mises à jour" de la glibc, et 1 mise à jour de GCC, python2.7 et python3.5. Sans compter je ne sais combien de paquets supprimés (voir ici). Sauf erreur de ma part, aujourd'hui, on est incapable de reconstruire from scratch l'image Debian telle qu'elle était disons le 5 mars 2019.

Par ailleurs, disons que Gimp dépende de Python3.5 qui a besoin de GCC pour être construit; ces 2 sont fournit pour le SDK. Gimp est construit avec ce SDK, disons SDK1. Puis imaginons que GCC recoive un patch de sécurité et Python3.5 est donc reconstruit avec cette "nouvelle" version de GCC, ce qui donne un SDK2. Ce changement est l'objet d'un commit dans le Gitlab de Freedesktop-SDK mais les mainteneurs ne changent pas la version du SDK, cela ne le mérite pas vraiment. Avec la même recette (qui ne dépend pas du commit ni runtime ni SDK mais uniquement de la version et oups! les mainteneurs ne l'ont pas changée), Gimp est maintenant construit avec ce SDK2. Et oh surprise, un bug apparait dans le Gimp-SDK2 et pas le Gimp-SDK1. Tout semble identique en apparence. Mais la chaine de dépendance n'est pas exactement la même. flatpack ne semble pas capable de le détecter. Est-ce exact ?

Ensuite oui dans un runtime, y a très probablement plus que nécessaire. Ça part évidemment du principe qu'un runtime est utilisé par de multiples applications et permet au contraire de partager la charge

Certes. Et en plus il faut aussi remarquer si 2 applications partagent une même dépendance (qui n'est pas dans le runtime), son mode de construction sera spécifiée à 2 endroits bien différents. Ceci a l'avantage d'avoir des bundles/application bien séparés; qui peuvent vivre leur vie chacune de leur côté. Et ceci à l'inconvénient de ne pas être mutualisé et donc de refaire du boulot déjà fait par d'autres.

Dans GNU Guix, on cherche à mutualiser toutes les briques pour pouvoir les composer. Au plus juste si on peut dire. :-)

---

Finalement, mon impression sans jamais avoir utilisé flatpack est que cela correspond à guix pack sans la machinerie de la reproductibilité bit-à-bit.

j'ai bien regardé le lien donné, mais quand j'ai vu la longue série de commande pour l'installation dite binaire, je me suis dit "un autre jour"; désolé!),

Hum? Il faut bien lire ;-) et surtout ne pas rater la Note cette page:

Note: We recommend the use of this shell installer script. The script automates the download, installation, and initial configuration steps described below. It should be run as the root user.

qui pointe vers ce script d'installation et il n'y a vraiment rien à faire! :-)

Je ne connais pas bien flatpack. Mais oui il est possible que flatpack a des fonctionnalités similaires, en revanche j'aurais plutôt l'impression que flatpack est une sous-ensemble en terme de possibilités. Bref! A voir.

Un autre point d'entrée serait peut-être cette discussion.

En outre y a-t-il un serveur/dépôt Guix de référence?

Le dépôt officiel est : https://git.savannah.gnu.org/git/guix.git.

Quand on fait un guix search ou guix install, ça installe depuis un dépôt unique?

Comparé à aptitude, les commandes aptitude update, aptitude search et aptitude install correspondent à guix pull, guix search et guix install. Cependant, il y a une différence majeure : avec aptitude quand le dépôt central (la liste de deb dans le fichier /etc/apt/source.list) est mis à jour par les mainteneurs de Debian, il n'est quasiment plus possible d'installer un paquet dans une version d'avant cette mise à jour. Sauf erreur de ma part.

Ce n'est pas le cas avec GNU Guix. Le comportement ressemble plus à celui de Git par exemple. Vous avez une copie locale qui se trouve dans un état, et dans le cas de GNU Guix, cet état est donné par guix describe; par exemple sur ma machine:

Generation 24   May 16 2019 13:12:59    (current)
  guix 6e633a5
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 6e633a510c53ac3130296bfd5ecf98506b499421

Connaissant ce état (commit), vous pouvez toujours y revenir (guix pull --commit=), quelque soit l'évolution ou autre mise à jour du dépôt officiel. Pour le dire autrement, une fois qu'un paquet est entré dans le dépôt officiel, il pourra toujours être reconstruit et à l'identique (modulo des changements hardware).

Dans un état donné, quand vous installez un paquet, par exemple guix install gimp, GNU Guix va regarder dans quel état il se trouve localement, puis il va regarder toutes les dépendences dont il a besoin pour installer Gimp. Et ensuite, il va regarder si tous les binaires correspondants se trouvent sur une des 2 fermes (substitute), si tel est le cas, il les téléchargent pour compléter l'installation. Sinon, il va utiliser le champ source de la définition du paquet pour le construire localement, ainsi que toutes les dépendances dont Gimp aurait besoin (spécifiées dans la définition du paquet).

Place à la transparence binaire ;-)

Je me permets de pointer la dernière partie de mon commentaire précédent.

Qui crée les paquets?

Les contributeurs du projets. ;-)
Si par paquet on entend le fichier de description dans un DSL scheme.

Et si par parquet on entend binaire, c'est tout le monde grâce à la transparence binaire. Actuellement, il y a 2 fermes de constructions mais il y a beaucoup de discussion sur la liste pour avoir une solution distribuée (IPFS, etc.)

Quelqu'un peut créer son propre dépôt?

Oui, il y a un mécanisme de channel. Par exemple, si je fais guix describe

Generation 24   May 16 2019 13:12:59    (current)
  bimsb d1cba4a
    repository URL: file:///home/simon/work/guix/bimsb
    branch: master
    commit: d1cba4a2cba1eb6c6c33328fea511b75dfcffe39
  guix 6e633a5
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 6e633a510c53ac3130296bfd5ecf98506b499421

On voit que j'ai un canal supplémentaire en local (file:/// mais cela pourrait être https:/// etc.).

Il n'y a qu'un dépôt officiel et la compatibilité avec les canaux n'est pas garantie ou pour le dire autrement la compatibilité du canal est la charge du mainteneur du dit canal. Dans ce canal bimsb, il y a des dépendances à LLVM par exemple mais la version de cette dépendence n'est actuellement pas trackée par le canal donc si le dépôt officiel change, le canal risque de casser. Cependant, le problème se résout en trackant des fichiers manifest. Bref, les outils sont là, il manque peut-être un peu d'UI. :-)

De toute manière, si c'est un logiciel libre autant pousser dans le dépôt officiel. ;-)

J'aurais bien testé un guix install gimp mais guix ne semble pas dispo sur Fedora. ;-(

Comme dit roptat: le mieux reste d'effectuer une installation avec le script d'installation officiel (voir manuel).

Notamment ça semble dire que ça installe aussi toutes les dépendances pour pouvoir compiler GIMP (ce que ne fait pas mon outil). Pour le coup, je veux bien plus de détails.

guix environment gimp --ad-hoc gimp crée donc un environnement pour construire gimp, dans lequel toutes les dépendances à la compilation de gimp sont disponibles, en plus de gimp lui-même.

J'ajouterai même l'option --pure, i.e., guix environment gimp --ad-hoc gimp --pure, qui déactive les variables d'environnement existantes. Il y a aussi les options --container ou --network (voir manuel).

quels sont les avantages de guile face à d'autres langages plus commun ?

Il est très facile d'écrire un Domain Specific Language (DSL).

Pour le dire autrement, on peut voir la définition d'un paquet comme simplement une liste de mot-clés (package, name, version, etc.) avec des déclarations. Au lieu de :

(package
  (name "ocaml-qcheck")
  (version "0.9")
  (source
    (origin
      (method url-fetch)
[...]

cela pourrait se lire :

package :
  name "ocaml-qcheck"
  version "0.9"
  source :
    origin :
      method url-fetch
[...]

et ceci est possible avec l'extension Wisp. C'est très déclaratif et il n'y a pas besoin de connaitre Lisp ou Scheme pour définir des paquets. Certes, il y a une petite barrière psychologique avec les parenthèses. :-)

D'expérience dans les "configurations", on veut pouvoir décrire des choses plus ou moins complexes et très souvent on arrive à vouloir des fonctions, des boucles, des tests, etc. Alors autant utiliser directement un langage qui va bien.

Pourquoi GNU Guile ? L'histoire dit que c'est un contributeur de Nix et qui était aussi co-mainteneur de GNU Guile. Et voilà Guile+Nix ;-)

Et comme GNU Guix est basé sur scheme qui permet de créer facilement des DSL, il y a une expérimentation très intéressante pour décrire un workflow d'exécution (comme dans les projets Snakemake, Common Workflow Language, Workflow Definition Language, Nextflow, etc.), c'est le Guix Workflow Language. Par exemple, présentations au FOSDEM 2017 ou 2019.

On m'a déjà "vendu" Nix une fois que c'était génial et tout et tout…

Si si c'est génial !! Enfin le changement de paradigme (approche déclarative et fonctionnelle) est vraiment très intéressant.

Déjà, nix n'est pas toujours compatible avec lui même selon les versions donc l'environnement stable sur un cluster qui évolue et se renouvelle

Je n'ai pas compris ?

Sinon, un point d'entrée concernant GNU Guix et le HPC est ce papier par les mainteneurs même si des petites choses se sont améliorées depuis.

On a toujours le même environnement… ce qui permet la reproductibilité. C'est un argument actuel en science. […] autant je suis sceptique en science pour du code ou ce mot, reproductible, est utilisé pour complètement autre chose.

Effectivement, le terme Reproducible Science est souvent utilisé sans vraiment définir de quoi on parle. N'est-ce pas un peu comme Big Data ou Machine Learning ? ;-)

Disons pour faire simple et rapide, il faut distinguer :

• répétable : le même code a tourné (plusieurs fois?) avec les mêmes données sur la même machine et les résultats sont similaires ;
• reproductible : le même code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires ;
• réplicable : un autre code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires.

Bon il faut aussi définir similaire. Quelle précision ? Arithmétique d'intervalle ? etc.

Disons que la distinction entre les 3 niveaux est admise mais la définition ne l'est pas toujours. Voir par exemple le journal ReScience.

Retrouver N fois le même résultat avec le même code n'a pas un intérêt fou, sauf à vérifier que le chercheur n'a pas triché, et encore…

N'est-ce pas essentiel dans le processus de revue par les pairs ?

En plus, ce coté reproductible pousse les personnes à faire du code non portable, aux API qui changent et dont le résultat est fortement dépendant des versions des modules de ceci et de cela. Telle et telle version marchent (même s'il y a un bogue et que c'est hyper dépendant des versions), hop je publie -> c'est reproductible par tout lecteur !

Je ne suis pas sûr de saisir la signification.

Parce que non ! Ce n'est pas reproductible par tout lecteur parce que justement c'est généralement hyper dépendant des versions et que cela fonctionne uniquement avec telle et telle version.

Il faut peut-être distinguer le champ d'application. Dans un contexte simulation, pour faire simple, on résout une équation (ou plusieurs) et en général c'est un gros code monolithique ; ou alors il y a un nombre de dépendances résonnables, dans le sens où même si c'est fastidieux, toutes les dépendances peuvent être installés à la main.
Dans d'autres contextes, ce sont des dizaines de "petits" codes qui interagissent entre eux (workflow ou pipeline) et chaque code a lui-même des dépendances et parfois 2 petits codes dépendent d'une même bibliothèque mais dans une version différente. Et parfois il y a des subtilités difficiles à trouver. Qui n'a pas passé des heures à chercher pourquoi cela fonctionne sur telle machine et pas sur telle autre alors que diantre! tout est pourtant identique… :-)

Il y a une notion peu mise en avant dans la reproductibilité, c'est la pérennité dans le temps. Comment s'assurer que ce que je publie aujourd'hui et que je ne maintiendrai probablement pas parce que le chercheur n'a pas forcément le temps, que mon code puisse être utilisable dans quelques mois ou années alors que tout un tas de bibliothèques aura évolué.

Disons qu'aujourd'hui, je dispose d'un code publié et open source qui dépend d'une dizaine de bibliothèques elles aussi open source. Disons que ce code a été écrit il y a 2 ans, il est en Python et dépend de bibliothèques en C, Fortran, C++ (de différentes saveurs) etc. qui ont toutes évoluées et dont l'API est devenu incompatible. Comment faire ?

• Soit j'essaie de mettre à jour le code Python. Mais quel travail, surtout s'il a été écrit par un autre ou un étudiant, s'il n'est pas ou peu documenté, etc.
• Soit j'arrive à retrouver toutes les versions utilisées des composants et à tout compiler. Mais encore quel travail.

Et au final, je ne trouve pas le même résultat que celui dans l'article. Est-ce que l'auteur s'est trompé ? a triché ? Ai-je fait une erreur dans la mise à jour ou est-ce vraiment la bonne version de la bibliothèque ? etc.

La Science est basée sur la vérification et comment vérifier ?

En clair, pour qu'il y ait reproductibilité, il faut qu'un déploiement soit possible dans le temps.

Or aujourd'hui, seule une solution pour la partie déploiement est proposée avec les conteneurs. Mais par exemple les Dockerfiles ne permettent pas une pérennité dans le temps. Par exemple avec Debian, est-ce que les binaires qu'apt-get tirent sont boostrappables ? Comment reconstruire aujourd'hui le même binaire présent dans l'archive en mai 2018 ? etc.

Pour le dire clairement, à mon sens, les solutions comme Docker ne tendent pas vers une démarche scientifique.

---

Pour schématiser, GNU Guix est peut-être l'outil le plus avancé pour la reproductibilité computationnelle en science.

1.
Il permet totalement de capturer un environnement avec guix describe. Par exemple :

  bimsb d1cba4a
    repository URL: file:///home/simon/work/guix/bimsb
    branch: master
    commit: d1cba4a2cba1eb6c6c33328fea511b75dfcffe39
  guix ccabb66
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: ccabb664ed55d44767e037bb73169be2ecf9449d

où guix est le dépôt (channel) "officiel" et bimsb est un dépôt local (qui pourrait aussi être sur une forge) qui me sert à tester (par exemple pour empaquetter des choses en R de BioConductor).

2.
Il permet de créer des environnements (comme virtualenv) très facilement. Par exemple :

guix environment --pure --ad-hoc emacs gcc-toolchain python python-numpy

créé un environnement isolé avec Emacs, GCC, Python et Numpy. Prêt pour travailler ! ;-)

3.
Il permet le déploiement facilement avec guix pack. Cela crée un fichier .tar.gz avec tous les binaires. Et il y a même une option pour générer une image Docker. Quelques explications sur le blog de GuixHPC.

4.
Il permet de restaurer un état antérieur du dépôt, par exemple au 1er mai 2018, avec guix pull --commit=bb6f94c71e. Maintenant, guix package -i emacs installera Emacs et ses dépendances exactement comme je l'aurais fait ce 1er mai 2018.
A ma connaissance, les channels ne sont pas encore supportés dans ce mécanisme… Un patch à proposer? :-)

Évidemment, il y a la possibilité d'utiliser des fichiers manifest. Plus d'explications sur guix pull c'est par là.

---

Qu'en est-il du Python ? Car en pratique, c'est souvent les modules Python qui sont "chiants" à packager vu que cela bouge tout le temps (trop souvent) et que les API changent… Avec Nix, mes amis font du conda ou du virtualenv… Bref, c'est pas une super réussite !

Même si guix import pypi fait une bonne partie du boulot, ce n'est pas forcément facile de suivre. Cela n'a pas à voir avec le gestionnaire de paquet mais avec la communauté. Pas assez de bras, pas de chocolat.

Si le paquet est déjà dans GNU Guix mais pas à la bonne version, en général il suffit de mettre à jour le numéro de version et le hash upstream, et puis guix build pour vérifier et voilà guix package -i. Les channels facilitent vraiment cela.

Si le paquet n'est pas dans GNU Guix, cela devient un boulot d'empaquetage. Et même si c'est assez facile avec GNU Guix---une fois passé la barrière psychologique des parenthèses ; je trouve que c'est plus facile que de faire un paquet Conda---cela reste un boulot d'empaquetage avec les trucs pénibles (quelque soit le gestionnaire de paquet).