Ce qui se passe
Ajouter une dépendance sous Nix demande toujours la même petite corvée : écrire
une url, ajouter un follows pour que le flake ne traîne pas sa propre copie
de nixpkgs, recommencer au suivant. La blague, dans la communauté, est que
chaque flake arrive avec son propre flake-utils.
Farid Zakaria a répondu par l'inverse de la fédération : omniflake, un dépôt qui contient près de douze mille flakes derrière une seule entrée.
inputs.omniflake.url = "github:fzakaria/omniflake";
inputs.omniflake.inputs.nixpkgs.follows = "nixpkgs";Une fois déclaré, on y pioche comme dans n'importe quelle entrée. Un paquet :
environment.systemPackages = [
omniflake.flakes.nh.packages.${system}.default
];Un overlay, ou un module NixOS :
nixpkgs.overlays = [ omniflake.flakes.rust-overlay.overlays.default ];
imports = [ omniflake.flakes.disko.nixosModules.disko ];Sans rien déclarer du tout, directement en ligne de commande :
nix run 'github:fzakaria/omniflake#flakes.nh.packages.x86_64-linux.default' -- --versionLe catalogue est consultable sur omniflake.com.
Pourquoi ça tient debout
L'objection saute aux yeux : un flake avec douze mille entrées devrait être inutilisable. Deux mécanismes l'en empêchent.
Le premier est le fichier de verrouillage. Un flake.lock ne fige pas seulement
vos propres entrées, il fige le graphe transitif entier. Deux flakes enfants
qui dépendent chacun de nixpkgs y inscrivent chacun leur nœud, à des commits
possiblement différents — d'où les nixpkgs et nixpkgs_2 qu'on voit apparaître
et que follows sert précisément à réécrire vers un nœud déjà présent.
Le second est l'évaluation paresseuse du langage Nix. Rien n'est récupéré ni évalué tant qu'on n'y touche pas. Le catalogue peut donc grossir sans que le coût suive : on ne paie que ce qu'on consomme.
Ce que ça change
La friction disparaît pour de bon : un seul follows à écrire, plus jamais de
nixpkgs en double par nouvelle dépendance, et un accès à un paquet ponctuel
sans toucher à sa configuration.
La contrepartie est visible et vaut d'être pesée : tout passe par un dépôt tenu par une seule personne. C'est exactement le point de centralisation que le modèle fédéré des flakes voulait éviter, et il devient un maillon de plus dans la chaîne d'approvisionnement de votre système. L'auteur ne s'en cache pas — sa position sur les flakes est qu'ils sont « meh », et omniflake est la réponse pragmatique à une friction qu'il refuse de subir plus longtemps.