Re: Nix et autres

Je crois que je peux répondre à la première de ces questions, étant contributeur :)

Sur la simplicité ou non de créer des paquets sur Guix, ça dépend du paquet en question. Certains sont vraiment très chiants, mais la difficulté est plutôt imputable au paquet : il sera aussi chiant à packager sur d'autres gestionnaires. La plupart du temps cependant, les paquets sont assez simples. Contrairement à nix qui construit un script bash avec son propre langage, les paquets dans Guix ont une forme plus déclarative et utilisent le concept de « système de construction ». Par exemple, pour un paquet python, on utilisera le python-build-system, pour un paquet cmake, on a le cmake-build-system, pour dune (outil de construction pour des paquets OCaml), on a le dune-build-system, pour un paquet qui utilise les autotools et suit la convention « configure, make, make install », on a le gnu-build-system, etc. En plus de ça, on a un outil d'import qui permet d'automatiser la création de recettes. Par exemple, si je veux importer le paquet OCaml qcheck, je lance guix import opam qcheck et j'obtiens :

(package
 (name "ocaml-qcheck")
 (version "0.9")
 (source
 (origin
 (method url-fetch)
 (uri "https://github.com/c-cube/qcheck/archive/0.9.tar.gz")
 (sha256
 (base32
 "1gczijq2vghb8aqn84w3c3h5lpxa7d0qnlmvzac48jqfly7d2cna"))))
 (build-system dune-build-system)
 (inputs
 `(("ocaml-base-bytes" ,ocaml-base-bytes)
 ("ocaml-base-unix" ,ocaml-base-unix)
 ("ocaml-qcheck-core" ,ocaml-qcheck-core)
 ("ocaml-qcheck-ounit" ,ocaml-qcheck-ounit)
 ("ocaml-odoc" ,ocaml-odoc)))
 (home-page "https://github.com/c-cube/qcheck/")
 (synopsis
 "QuickCheck inspired property-based testing for OCaml.")
 (description
 "This module allows to check invariants (properties of some types) over
randomly generated instances of the type. It provides combinators for
generating instances and printing them.")
 (license #f))

qui est vraiment très facile à lire. le seul truc un peu bizarre, ce sont les parenthèses (en fait c'est une expression Guile, une implémentation de Scheme) et le contenu de « inputs » avec ses apostrophes et ses virgules, mais dans l'ensemble on peut simplement se dire que ce sont des éléments de syntaxe un peu étranges et si on ne connait pas le langage, pas besoin de l'apprendre. Avec cette recette, on peut construire le paquet en question, il faut juste nettoyer un peu (par exemple retirer les pseudo-paquets ocaml-base-bytes et ocaml-base-unix et choisir une licence appropriée). Ce paquet et ses dépendances sont déjà dans Guix, mais la plupart du temps, l'option -r permet aussi d'importer récursivement les dépendances qui ne sont pas encore dans la distribution.

Il y a aussi des importateurs pour d'autres sources, comme pypi, cpan, hackage, elpa, gem, cran, et d'autres.

Pour les autres questions, je ne peux pas répondre avec précision, mais je sais au moins que les deux co-mainteneurs, Ludo et Ricardo maintiennent une infrastructure qui utilise Guix dans le contexte du calcul haute-performance. Peut-être que la lecture de la page du projet guix-hpc permettra de répondre à tes questions ?

Je peux aussi te dire que lorsque j'entends parler de recherche reproductible de mon côté, j'entends surtout parler de docker et de technologies similaires : il s'agit de faire un snapshot pour le redistribuer aux collègues. Dans tous les cas, je préfère guix qui permet de reconstruire le snapshot de manière transparente, et de facilement jouer avec (par exemple, reconstruire exactement le même snapshot, mais avec une version de tel logiciel différent, ou en mettant tous les paquets à jour).

Pour ce qui est de la dépendance au noyau effectivement, Nix comme Guix supposent que l'interface du noyau ne change pas de comportement et ignore totalement sa version.