Flakes : comprendre la fonctionnalité la plus utilisée (et la plus débattue) de Nix

Une fonctionnalité aujourd'hui adoptée par la majorité des utilisateurs de Nix, recommandée par défaut dans une grande partie des projets open source, porte encore, sept ans après son introduction, l'étiquette officielle "expérimentale". Cette fonctionnalité, ce sont les flakes. Chez Hebeko, nous travaillons régulièrement avec des environnements Nix pour nos clients, et cette ambiguïté de statut revient systématiquement dans les échanges avec les équipes techniques qui évaluent l'outil. Cet article expose les termes du débat et ses points de conflit.

Le problème que les flakes viennent résoudre

Nix se distingue des autres gestionnaires de paquets par une promesse forte : fournir la même expression à deux machines différentes doit produire un résultat strictement identique, au bit près. Cette promesse est l'un des principaux arguments en faveur de l'adoption de Nix en entreprise, notamment pour les équipes soucieuses de traçabilité et de conformité de leurs environnements de production.

Avant l'introduction des flakes, cette promesse avait une faille. Les projets Nix s'appuyaient sur des channels, des canaux globaux et mutables susceptibles de différer d'une machine à l'autre, ainsi que sur un chemin de recherche (NIX_PATH) dont la résolution dépendait de l'environnement local. Deux collaborateurs travaillant sur un même dépôt pouvaient, sans modification de code, obtenir des résultats de build différents.

Le fonctionnement des flakes

flowchart LR
    A["flake.nix<br/>déclare les entrées<br/>(nixpkgs, flakes tierces...)"] --> B["flake.lock<br/>épingle chaque entrée<br/>à un commit précis"]
    B --> C["Reproductibilité bit à bit<br/>nix develop produit le même<br/>environnement partout"]

En 2019, Eelco Dolstra, créateur de Nix, propose les flakes en réponse à ce problème. Le principe repose sur quatre éléments :

• Un fichier flake.nix, qui déclare explicitement l'ensemble des dépendances d'un projet.
• Un fichier flake.lock, généré automatiquement, qui épingle chacune de ces dépendances à un commit précis.
• Une évaluation dite "pure", indépendante des variables d'environnement et de l'état local de la machine.
• Une structure de sortie standardisée (packages, devShells, nixosConfigurations), qui rend tout projet immédiatement compréhensible par une autre équipe, sans documentation additionnelle.

Pour une organisation, cloner un dépôt et exécuter nix develop suffit à obtenir un environnement de développement identique à celui de son auteur, sans étape d'installation manuelle.

Un désaccord persistant au sein de la communauté

Ce gain n'a cependant jamais suffi à produire un consensus au sein de la communauté Nix. Ce désaccord éclaire les précautions à prendre lors d'une adoption en entreprise.

Premier point de friction : le mode d'introduction de la fonctionnalité

Une partie de la communauté a mal accueilli l'abandon en cours de route de la RFC initiale consacrée aux flakes. La fonctionnalité a pourtant fini par être intégrée à Nix. D'autres contributeurs n'étaient pas opposés, par principe, à l'intégration de fonctionnalités expérimentales sans RFC formelle (une pratique courante dans le projet), mais leur reprochaient de ne s'être, dans les faits, jamais comportées comme des fonctionnalités réellement expérimentales : peu de retours en arrière, peu d'itérations profondes sur la conception, et une adoption si rapide qu'elle a rendu, de fait, tout changement de rupture politiquement difficile à assumer.

Deuxième point de friction : des choix de conception contestés

flowchart TD
    P["Votre projet"] --> A["Flake A<br/>nixpkgs @ a1b2"]
    P --> B["Flake B<br/>nixpkgs @ c3d4"]
    P --> C["Flake C<br/>nixpkgs @ e5f6"]
    A --> W["Trois copies distinctes de nixpkgs<br/>temps de build et espace disque potentiellement multipliés"]
    B --> W
    C --> W

Plusieurs utilisateurs signalent des frictions opérationnelles concrètes. Chaque flake tierce peut embarquer sa propre version de nixpkgs : si un projet dépend par exemple de trois flakes tierces non harmonisées, chacune peut apporter sa propre copie de nixpkgs à un commit différent, ce qui peut multiplier les temps de build et l'espace disque utilisé. Le couplage étroit avec Git est aussi un piège fréquent pour les nouveaux utilisateurs, qui doivent penser à indexer (git add) chaque modification avant de reconstruire, sous peine de la voir silencieusement ignorée. Ces deux points allongent les temps de développement et sont à anticiper en environnement professionnel.

Troisième point de friction : une conception perçue comme trop spécifique

Une partie des critiques soutient que les flakes auraient été conçues, à l'origine, pour répondre aux besoins d'un client unique, et que leur statut prolongé de fonctionnalité expérimentale limiterait, dans les faits, la probabilité que les lacunes de l'implémentation soient corrigées. Cet argument, bien que formulé de manière parfois polémique, revient régulièrement dans les discussions techniques et ne peut être écarté sans examen.

La position des défenseurs des flakes

Les partisans des flakes répondent à ces critiques. Graham Christensen, cofondateur de Determinate Systems (société où travaille également Eelco Dolstra), défend de longue date l'idée que les flakes sont, dans les faits, déjà stables, et que leur étiquette expérimentale n'aurait jamais dû perdurer aussi longtemps. Sa position se résume ainsi : les critiques les plus fréquentes, à savoir la duplication de nixpkgs, l'absence de support natif pour la compilation croisée et le format du fichier de verrouillage, sont, selon lui, soit mal posées, soit sans lien direct avec la conception des flakes, soit déjà en cours de traitement par la communauté. Son entreprise a d'ailleurs publié sa propre distribution de Nix, dans laquelle les flakes sont marquées stables par défaut.

La majorité des utilisateurs actuels de Nix utilisent d'ailleurs les flakes, un usage de facto qui pèse dans l'appréciation de leur maturité.

Le compromis institutionnel : la RFC 0136

La gouvernance du projet Nix a tenté de sortir de cette impasse par un texte de référence, la RFC 0136. Ce texte établit d'abord des principes généraux sur l'évolution de Nix, avant de définir un plan de stabilisation progressif : dans un premier temps l'interface en ligne de commande, puis, dans un second temps seulement, les flakes elles-mêmes, dont la conception finale devra encore faire l'objet d'une nouvelle RFC.

L'auteur du texte demande explicitement aux "sceptiques des flakes" de ne pas rouvrir le débat sur le fond de la conception, afin d'éviter de reproduire des discussions longues et sans issue observées par le passé. Cette précaution indique à elle seule le niveau de tension accumulé sur ce sujet au sein du projet.

La RFC reconnaît aussi que les flakes sont très largement adoptées par les nouveaux utilisateurs de Nix, au point d'être de facto l'usage majoritaire, ce qui réduit la marge de manœuvre pour toute remise en cause de leur fonctionnement.

Recommandations pour une adoption en entreprise

Nos recommandations pour une organisation qui évalue les flakes :

1. L'adoption des flakes n'est pas, à ce stade, un choix technique risqué. Aucune des parties prenantes du débat, y compris les plus critiques, n'envisage sérieusement leur abandon.
2. L'étiquette "expérimentale" protège principalement contre des changements de rupture ciblés, et non contre un retrait de la fonctionnalité. Activez explicitement le paramètre (experimental-features = nix-command flakes) et suivez les évolutions annoncées du format de verrouillage.
3. Le couplage avec Git est le principal point de friction pour les équipes découvrant Nix. Une modification non indexée est, pour l'outil, une modification qui n'existe pas.
4. Les dépendances tierces nécessitent une vigilance particulière, en particulier celles peu maintenues. Elles présentent souvent plus de risque que la conception des flakes elle-même.

Où en est le débat

Le débat entourant les flakes ne semble pas près de se refermer. Les deux camps défendent une exigence légitime : la rigueur du processus de stabilisation pour les uns, la reconnaissance d'un usage déjà massif pour les autres. Pour une organisation qui évalue Nix aujourd'hui, connaître ce contexte permet d'anticiper les points de friction au lieu de les découvrir en cours de projet.

Hebeko accompagne l'adoption de NixOS et des flakes en production. Voir NixOS chez Hebeko ou contactez-nous.

---

Sources

1. RFC 0136, "A plan to stabilize the new CLI and Flakes incrementally", dépôt NixOS/rfcs
2. Texte intégral de la RFC 0136
3. Discussion communautaire, "Development shells with Nix: four quick examples", Lobsters
4. Discussion communautaire, "NixOS RFC 136 approved", Hacker News
5. RFC 0049, "Flakes", proposition originale d'Eelco Dolstra, dépôt NixOS/rfcs
6. Graham Christensen, "Experimental does not mean unstable", Determinate Systems
7. Discussion, "Why are flakes still experimental?", NixOS Discourse
8. Documentation officielle, "Flakes", nix.dev