Que la partie core du projet soit un mélange de C, Rust, Python et de Bash ne me pose pas de soucis outre mesure du moment que pour l'empaqueteur final n'a qu'à gérer un fichier nix
Je pense que c'est là qu'il y a une grande différence de philosophie. Guix est en fait une bibliothèque Scheme avec une API. Donc tu peux facilement étendre, modifier, adapter en Scheme. Il y a une continuité entre la partie core et les scripts que tu peux écrire pour transformer tes paquets, utiliser des services externes, etc.
Par exemple dans cette tentative, j'interroge un service externe des fermes de calculs Guix pour lister les paquets non-reproductibles par type de constructeurs (build system, genre CMake, OCaml, Haskell, etc.).
Quelque part, c'est un peu la même philosphie qu'Emacs : c'est le même langage utilisé par le core qui permet aussi de configurer. Cela donne l'extensibilité. Après, certes on adhére ou non car c'est du Lisp. :-)
[^] # Re: Similaire à NixOS
Posté par zimoun . En réponse à la dépêche GNU Guix 1.2.0 est publié. Évalué à 2.
Je pense que c'est là qu'il y a une grande différence de philosophie. Guix est en fait une bibliothèque Scheme avec une API. Donc tu peux facilement étendre, modifier, adapter en Scheme. Il y a une continuité entre la partie core et les scripts que tu peux écrire pour transformer tes paquets, utiliser des services externes, etc.
Par exemple dans cette tentative, j'interroge un service externe des fermes de calculs Guix pour lister les paquets non-reproductibles par type de constructeurs (build system, genre CMake, OCaml, Haskell, etc.).
Quelque part, c'est un peu la même philosphie qu'Emacs : c'est le même langage utilisé par le core qui permet aussi de configurer. Cela donne l'extensibilité. Après, certes on adhére ou non car c'est du Lisp. :-)