La syntaxe précédente était bien plus simple et moins verbeuse, et il aurait été facile de changer juste la sémantique des "chemins" (la syntaxe <nixpkgs>) pour gérer tous les cas gérés par les flakes. Par exemple, aujouter un .lock à côté des default.nix.
Les flakes ont été imposés sans aucune discussion ni RFC de la communauté.
La vision de "bibliothèques Nix" est à mon avis un gros problème de sécurité, en fragmentant l'écosystème et en le rendant les audits encore plus difficiles.
Le design lui-même a plein de trous: par exemple, le nixpkgs implicite ou encore nix run qui peut permettre de surcharger les noms entre "apps" et "packages". Le manque de stabilisation encourage l'écriture d'une grande quantité de code Nix reposant sur des bases fragiles.
Enfin, à l'échelle d'une organisation, l'articulation entre les différents projets n'est pas particulièrement simplifiée par les flakes, contrairement à ce qu'on entend parfois.
[^] # Re: Flakes
Posté par pmeunier . En réponse à la dépêche Elpe, un compromis entre NixOS et Ubuntu. Évalué à 3.
Je reproche plusieurs choses aux flakes:
La syntaxe précédente était bien plus simple et moins verbeuse, et il aurait été facile de changer juste la sémantique des "chemins" (la syntaxe
<nixpkgs>) pour gérer tous les cas gérés par les flakes. Par exemple, aujouter un .lock à côté des default.nix.Les flakes ont été imposés sans aucune discussion ni RFC de la communauté.
La vision de "bibliothèques Nix" est à mon avis un gros problème de sécurité, en fragmentant l'écosystème et en le rendant les audits encore plus difficiles.
Le design lui-même a plein de trous: par exemple, le nixpkgs implicite ou encore
nix runqui peut permettre de surcharger les noms entre "apps" et "packages". Le manque de stabilisation encourage l'écriture d'une grande quantité de code Nix reposant sur des bases fragiles.Enfin, à l'échelle d'une organisation, l'articulation entre les différents projets n'est pas particulièrement simplifiée par les flakes, contrairement à ce qu'on entend parfois.