veilletech.fr
31 août Feed du jour
#08 OUTILS Article

Omniflake : douze mille flakes en une entrée

Un seul follows, et le reste suit.

omniflake rassemble près de douze mille flakes Nix derrière une seule entrée, qu'on déclare une fois et dans laquelle on pioche paquets, overlays et modules NixOS. L'évaluation paresseuse du langage Nix fait que le coût reste proportionnel à ce qu'on utilise réellement, pas à la taille du catalogue.

2 min de lecturevidéo 1:11
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Pourquoi ça tient debout
  3. Ce que ça change
  4. À retenir

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.

NIX
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 :

NIX
environment.systemPackages = [
  omniflake.flakes.nh.packages.${system}.default
];

Un overlay, ou un module NixOS :

NIX
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 :

Terminal
nix run 'github:fzakaria/omniflake#flakes.nh.packages.x86_64-linux.default' -- --version

Le 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.

Source : Farid Zakaria — One flake to rule them all