flatpak et snap sont des solutions pour créer des snapshot pour faire tourner un logiciel. Je ne me suis jamais trop intéressé à ces technos, mais ce que j'en comprends, c'est qu'il est très difficile de reproduire le même environnement ou d'en modifier des bouts. Guix n'est pas exactement un concurrent dans ce sens (ou peut créer des conteneurs docker ou singularity, et rien n'interdit d'ajouter la prise en charge de flatpak ou snap dans le futur), mais une approche radicalement différente pour créer ces conteneurs.
Dans docker (que je connais mieux) on utilise un dockerfile (dans le meilleur des cas) pour spécifier des commandes à lancer. C'est une manière très impérative de faire, et qui dépend beaucoup de l'état extérieur au conteneur ou à docker. Je crois que c'est aussi le cas pour les autres technos. Avec Guix, tu peux déclarer de manière fonctionnelle et sans état (autre que guix lui-même). C'est pour ça qu'on parle de gestion des paquets fonctionnelles : la même entrée (guix et un manifeste) donnera toujours la même sortie (le même conteneur, environnement, VM, ...). À l'inverse, les outils par défaut de flatpak et autres ne permettent pas de faire ça. Si on considère que la plupart des dockerfiles commencent par apt-get update, on comprendra facilement qu'un dockerfile qui marche une fois ne fonctionnera peut-être plus la prochaine fois.
Le dépôt de Guix de référence est son code source, sur savannah. Par défaut, seuls les paquets de ce dépôt sont présents. Ils sont mis à jour par guix pull qui récupère la dernière version de ce code, et donc des paquets. Il y a aussi deux fermes de constructions qui fournissent des binaires, mais elles sont facultatives : avec la transparence binaire, on peut aussi bien compiler soit-même que télécharger des « substituts ». D'ailleurs guix va compiler les paquets lui-même s'il n'arrive pas à contacter de ferme de construction ou qu'il ne trouve aucun substitut pour certains paquets. Il y a un mécanisme de canaux qui permet d'étendre la collection de paquets de Guix. Pour cela, il y a juste besoin de déclarer les canaux à utiliser dans ~/.config/guix/channels.scm. C'est expliqué dans le manuel, et voici quelquesexemples de canaux. Ces canaux ne sont pas officiels.
Je crois qu'il y a un paquet dans les dépôts non officiels de fedora (copper ou un truc comme ça), mais le mieux reste d'effectuer une installation avec le script d'installation officiel.
2)
guix environment gimp crée un environnement similaire à celui utilisé pour compiler réellement gimp. Il y a toutes les dépendances à la compilation déclarées dans la recette de gimp (dont make, gcc, et toutes les bibliothèques et outils nécessaires). C'est tout. Gimp lui-même n'est pas disponible dans cet environnement. Si on veut ajouter des programmes à l'environnement (par exemple gimp lui-même), il y a une option --ad-hoc qui fait ça. 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.
[^] # Re: Plusieurs questions
Posté par roptat . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 5.
1)
flatpak et snap sont des solutions pour créer des snapshot pour faire tourner un logiciel. Je ne me suis jamais trop intéressé à ces technos, mais ce que j'en comprends, c'est qu'il est très difficile de reproduire le même environnement ou d'en modifier des bouts. Guix n'est pas exactement un concurrent dans ce sens (ou peut créer des conteneurs docker ou singularity, et rien n'interdit d'ajouter la prise en charge de flatpak ou snap dans le futur), mais une approche radicalement différente pour créer ces conteneurs.
Dans docker (que je connais mieux) on utilise un dockerfile (dans le meilleur des cas) pour spécifier des commandes à lancer. C'est une manière très impérative de faire, et qui dépend beaucoup de l'état extérieur au conteneur ou à docker. Je crois que c'est aussi le cas pour les autres technos. Avec Guix, tu peux déclarer de manière fonctionnelle et sans état (autre que guix lui-même). C'est pour ça qu'on parle de gestion des paquets fonctionnelles : la même entrée (guix et un manifeste) donnera toujours la même sortie (le même conteneur, environnement, VM, ...). À l'inverse, les outils par défaut de flatpak et autres ne permettent pas de faire ça. Si on considère que la plupart des dockerfiles commencent par
apt-get update, on comprendra facilement qu'un dockerfile qui marche une fois ne fonctionnera peut-être plus la prochaine fois.Le dépôt de Guix de référence est son code source, sur savannah. Par défaut, seuls les paquets de ce dépôt sont présents. Ils sont mis à jour par
guix pullqui récupère la dernière version de ce code, et donc des paquets. Il y a aussi deux fermes de constructions qui fournissent des binaires, mais elles sont facultatives : avec la transparence binaire, on peut aussi bien compiler soit-même que télécharger des « substituts ». D'ailleurs guix va compiler les paquets lui-même s'il n'arrive pas à contacter de ferme de construction ou qu'il ne trouve aucun substitut pour certains paquets. Il y a un mécanisme de canaux qui permet d'étendre la collection de paquets de Guix. Pour cela, il y a juste besoin de déclarer les canaux à utiliser dans~/.config/guix/channels.scm. C'est expliqué dans le manuel, et voici quelques exemples de canaux. Ces canaux ne sont pas officiels.Je crois qu'il y a un paquet dans les dépôts non officiels de fedora (copper ou un truc comme ça), mais le mieux reste d'effectuer une installation avec le script d'installation officiel.
2)
guix environment gimpcrée un environnement similaire à celui utilisé pour compiler réellement gimp. Il y a toutes les dépendances à la compilation déclarées dans la recette de gimp (dont make, gcc, et toutes les bibliothèques et outils nécessaires). C'est tout. Gimp lui-même n'est pas disponible dans cet environnement. Si on veut ajouter des programmes à l'environnement (par exemple gimp lui-même), il y a une option--ad-hocqui fait ça.guix environment gimp --ad-hoc gimpcré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.