Con el auge de Nix como gestor de paquetes y configuración, la necesidad de compartir proyectos y dependencias de manera clara y reproducible se volvió una prioridad dentro de su comunidad. Durante años, los usuarios emplearon métodos improvisados para consumir un proyecto dentro de otro, muchas veces pasando instancias evaluadas como argumentos, lo cual resultaba poco práctico y difícil de mantener. Este escenario condujo a la búsqueda de una solución que tratara las dependencias de forma declarativa y reproducible, y que evitara el uso de estados mutables del sistema como canales y variables de entorno. En respuesta a estos desafíos nació Nix Flakes, una propuesta que prometía modernizar el ecosistema y superar las limitaciones de los archivos legacy default.nix y shell.
nix, tan usados hasta entonces. Sin embargo, la realidad ha mostrado que Flakes no cumplió con sus objetivos y, de hecho, han representado un estancamiento y problemas adicionales, lo que plantea dudas sobre su futuro y utilidad real. Nix Flakes surgieron con la intención de eliminar la dependencia de estados externos e impuros, como nix-channel y NIX_PATH, para garantizar que la evaluación de proyectos sea pura, es decir, sin acceso a variables de entorno ni estados mutables del sistema. Además, incluía la capacidad de bloquear insumos (inputs) para asegurar que las dependencias fueran reproducibles en cualquier entorno y un esquema estándar para exportar interfaces conocidas que facilitaran la interoperabilidad. Estas características teóricas parecían revolucionarias y prometían mejorar el desarrollo en Nix significativamente.
Sin embargo, con el paso del tiempo y el uso práctico, las debilidades de Flakes se hicieron evidentes y la funcionalidad no solo dejó de mejorar sino que fue estancándose, con pull requests cruciales pendientes desde hace años. Uno de los problemas fundamentales radica en la imposibilidad para Flakes de cargar cualquier cosa fuera de sí mismas, es decir, solo pueden importar otros Flakes o archivos en formatos específicos, pero no proyectos heredados u otros formatos fuera de ese estándar. Este enfoque rígido provoca una serie de inconvenientes, dado que la gran mayoría de proyectos escritos en Nix no se presentan como Flakes, sino como archivos tradicionales, haciendo necesaria la importación manual y rompiendo la fluidez que se esperaba. Más irónico resulta que Nixpkgs, el repositorio más importante de paquetes de Nix y uno de los pilares fundamentales del ecosistema, con frecuencia debe ser importado manualmente, lo que cuestiona la propia implementación y diseño de Flakes al no poder gestionar siquiera esta integración básica. La experiencia de usuario con Flakes también es limitada en cuanto a configuración y personalización.
Al ser considerados de primera clase, uno esperaría funciones para ajustar o parametrizar la forma en que se usan o interactúan con los Flakes, pero esto no sucede. Flakes permiten reemplazar insumos —por ejemplo, para actualizar versiones menores de dependencias— pero no ofrecen mecanismos para configuraciones complejas o personalizaciones que son habituales en los proyectos Nix. Algunos ejemplos comunes de esta necesidad incluyen el uso de override y overrideAttrs en los paquetes Nix, opciones que no pueden implementarse directamente con Flakes debido a su naturaleza estática y cerrada. El grado de extensibilidad es otro problema serio. El sistema de esquemas para Flakes, propuesto por Determinate Systems, aún no ha logrado resolver la falta de reglas estrictas o validaciones sobre qué atributos pueden exponerse o de qué forma.
Esta ausencia de tipo o validación hace que los valores expuestos sean inconsistentes y dificulta una interoperabilidad real. Además, la comunidad ha tenido que desenvolver librerías y abstracciones adicionales para compensar esta carencia, lo que añade complejidad y contradice el ideal de sencillez que impulsó la creación de Flakes. En paralelo, las restricciones sobre la evaluación de Flakes resultan contradictorias y poco prácticas. Por un lado, los archivos de entrada flake.nix deben evaluarse estáticamente, limitando lo que pueden contener a un subconjunto reducido del lenguaje Nix, lo que imposibilita el uso de variables, funciones e importaciones complejas.
Eso hace que muchas tareas habituales en Nix sean engorrosas o imposibles dentro del esquema de Flakes. Por otro lado, Flakes permiten modificar la configuración de Nix desde su propia definición, lo que presenta riesgos de seguridad y requiere cautela extrema del usuario. Un error mínimo en esta configuración puede tener consecuencias críticas, ya que se otorga acceso elevado a la máquina. Además, el debate en la comunidad respecto a la estabilidad y futuro de Flakes ha generado confusión. Aunque formalmente se mantienen como una característica experimental sin fecha clara para su estabilización, algunas entidades declararon la funcionalidad como estable, mientras otros desarrolladores la consideran aún altamente inestable y problemática.
Esta ambigüedad y falta de progreso visible han erosivado la confianza y motivación para su adopción masiva. La suma de todos estos factores conduce a un escenario donde Nix Flakes no solo no han solucionado los problemas que pretendían abordar, sino que han generado nuevos dolores de cabeza y dificultado la evolución natural del ecosistema Nix. Por ello, muchos en la comunidad han decidido dejar de lado esta propuesta y buscar alternativas o métodos propios que respondan mejor a las necesidades reales y prácticas. En conclusión, la historia de Nix Flakes es un claro ejemplo de cómo una innovación con intenciones acertadas puede fracasar si sus fundamentos no consideran profundamente la compatibilidad, flexibilidad y seguridad necesarias para el uso real. Su rigidez, limitaciones técnicas, falta de configurabilidad y el estancamiento en desarrollo han llevado a que su adopción fracase y su futuro sea incierto.
Para que el ecosistema Nix continúe creciendo y afianzándose, es indispensable que se encuentren soluciones más adaptadas a las complejidades del mundo real, antes que insistir en un modelo que lleva años demostrando su incapacidad para evolucionar y cumplir expectativas. El momento de aprender de esta experiencia y avanzar es ahora.
