omniflake: 12.000 Nix flakes detrás de un solo input

Qué es omniflake y por qué importa a quien opera infraestructura

Farid Zakaria presenta omniflake, un proyecto experimental en el ecosistema Nix que condensa cerca de 12.000 flakes detrás de un único input. La promesa: añadir un solo github:fzakaria/omniflake al flake.nix y, desde ahí, acceder de forma perezosa a casi cualquier paquete, overlay o módulo de NixOS sin tener que declarar dependencias transitivas una por una. El propio autor lo define con humor: "omniflake es mi pastel" — quiero la federación de las flakes, pero también la simplicidad de la centralización.

El artículo, publicado el 28 de agosto en su blog personal, documenta todo el camino técnico: por qué nació el proyecto, qué problemas detectó en cómo NixOS maneja flakes hoy y cómo la evaluación perezosa del lenguaje Nix permitió que un "mega flake" fuese viable en producción.

Por qué añadir una flake sigue siendo un dolor de cabeza

Quien haya trabajado con Nix reconoce el patrón. Para usar disko, por ejemplo, hay que declarar su url y luego un follows que apunte a nixpkgs para evitar que la dependencia arrastre su propia copia. El proceso se repite con la siguiente flake, y con la siguiente. Este meme es tan conocido en la comunidad que tiene nombre: "1000 instancias de flake-utils", documentado por Nixcademy.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La raíz del problema está en el flake.lock. Aunque follows ayuda a colapsar duplicados, sigue habiendo casos donde dos flakes hijas dependen de versiones distintas de nixpkgs, generando nodos separados en el grafo. Cada input nuevo suma ruido al lockfile y al grafo de evaluación. Zakaria lo resume así: "el coste no estaba en la evaluación, estaba en cómo Nix nombra los nodos cuando hay colisiones".

El truco: la pereza del lenguaje Nix

Nix es un lenguaje de evaluación perezosa: si un output no toca un input, ese input nunca se descarga. Zakaria demuestra esto con un experimento: corrompe un hash en el lock para hacerlo irresoluble y, aun así, un nix eval .#justB funciona. Solo cuando fuerza el uso del input envenenado, Nix devuelve un 404.

Esa propiedad es la que hace posible omniflake. El proyecto declara solo cinco inputs reales (nixpkgs más cuatro librerías pequeñas) y mantiene una tabla JSONL con pins para los ~12.000 flakes que ofrece. Cuando alguien pide omniflake.flakes.disko, una librería interna replica lo que Nix haría con un lockfile: descarga el pin, lee el flake.lock del repositorio, importa sus inputs y evalúa sus outputs. Solo se paga por lo que se usa.

El propio artículo lo demuestra en cifras: nix flake lock con omniflake tarda alrededor de 1,5 segundos y solo añade seis nodos al lock, sin descargar ninguna de las miles de flakes detrás.

El obstáculo técnico: un bug cuadrático en Nix

El primer intento de Zakaria fue el camino obvio: meter las ~12.000 flakes como inputs directos en un flake.nix único. La idea funcionaba en teoría, pero el flake.lock tardaba demasiado en generarse. La causa no era evaluación, sino nomenclatura: cuando dos nodos comparten nombre, Nix los renombra añadiendo sufijos _2, _3, etc., empezando la búsqueda desde _2 cada vez. Con flakes que comparten inputs como systems, las colisiones se disparaban y el coste se volvía cuadrático.

Zakaria envió un parche a NixOS (PR #16387) que recuerda el sufijo máximo usado por nombre y continúa desde ahí. El speedup fue dramático: ~21x más rápido para 4.000 inputs. Aun así, ese enfoque era un callejón sin salida: si un solo input fallaba al bloquearse, todo el lock se abortaba. La solución final fue tratar las flakes no como inputs, sino como una tabla de pins que el loader interno consulta bajo demanda.

Qué cambia para quien opera infraestructura

omniflake no es solo una curiosidad técnica. Para equipos que mantienen repositorios de configuración NixOS — desde plataformas Bitcoin hasta sistemas internos de startups — simplifica un workflow que llevaba años siendo ruidoso.

Acciones concretas que podés tomar hoy:

Evaluar omniflake en un entorno de staging: añadilo como input en un flake de prueba y comprobá que podés referenciar omniflake.flakes.disko.nixosModules.disko o omniflake.flakes.nh.packages.x86_64-linux.default sin declarar disko ni nh como inputs separados. El proyecto publica su índice en omniflake.com.
Usar pinned vs flakes según el caso: omniflake.pinned.disko te da la flake exactamente como su autor la cerró; omniflake.flakes.disko viene con nixpkgs y otras dependencias ya unificadas. Si necesitás reproducibilidad bit-a-bit, usá pinned. Si querés evitar divergencias de nixpkgs, usá flakes.
Aprovechar overrides para tu política interna: omniflake.lib.withOverrides { nixpkgs = nixpkgs-stable; } te permite sustituir dependencias de forma centralizada sin tocar cada flake individual.

El artículo también deja una lección más amplia para founders: cuando una herramienta tiene fricción repetitiva, a veces la respuesta no es convencer a todos de hacer las cosas "bien" (cada uno con su follows), sino construir una capa que abstraiga la fricción. omniflake es exactamente eso: una capa de centralización opcional sobre un sistema federado.

El contexto más amplio: Nix sigue creciendo, pero con barreras de entrada

Nix nació como proyecto de investigación de Eelco Dolstra en 2003 y ha ido ganando tracción en nichos donde la reproducibilidad es crítica, como la infraestructura de proyectos Bitcoin: el repositorio Nix-Bitcoin, por ejemplo, distribuye paquetes de Bitcoin Core, Core Lightning y BTCPay Server como módulos NixOS para que cualquiera pueda reproducir un nodo desde cero, según reportó Bitcoin Magazine.

Su adaptación a macOS, nix-darwin, también está atrayendo a desarrolladores que quieren reproducir setups completos — paquetes, servicios, incluso aplicaciones del Mac App Store — desde un único archivo declarativo, según cubrió Better Stack. Pero la adopción masiva sigue limitada por la curva de aprendizaje del lenguaje Nix y por la complejidad de las flakes.

omniflake apunta directamente a esa barrera de entrada: reduce la fricción operativa sin obligar al usuario a entender cada arista del grafo de dependencias. Para founders técnicos que ya evalúan Nix como opción de infraestructura, vale la pena seguir el proyecto aunque sea como experimento.