El proyecto nixpkgs-multiverse ofrece un índice que mapea (atributo, versión) con la revisión de Nixpkgs que lo distribuyó. Hasta ahora esos datos se almacenan en archivos JSON: versions.json, de 5,3 MiB, e history.json, de 7,5 MiB, que cubren 305.492 versiones de 31.904 paquetes a lo largo de 1.534 revisiones. El problema es que builtins.fromJSON, la función de Nix para leer esos ficheros, se evalúa de forma eager: cualquier acceso parsea los 5,3 MiB completos y materializa todas las entradas en el heap, por lo que consultar un solo paquete cuesta lo mismo que consultarlos todos. SQLite permitiría codificar los datos de forma compacta y definir consultas declarativas, pero Nix no dispone de un builtins.sqlite. El artículo describe tres vías para sortear esa limitación, cada una con un compromiso distinto. La primera recurre a builtins.exec, disponible desde Nix 1.11.9 (abril de 2017), que ejecuta un programa arbitrario y parsea su salida como expresión Nix. Invocar sqlite3 desde ahí permite emitir directamente un attrset sin formato de serialización intermedio; el coste es un fork, un exec y un reparseo por consulta. La segunda opción es builtins.importNative, presente desde 1.8 (diciembre de 2014), que carga una librería compartida, localiza un símbolo y lo invoca. Escribiendo una primitiva en C++ con la API de Nix que cachee los handles de SQLite, los procesos de apertura y las páginas del b-tree se reutilizan entre llamadas, eliminando la penalización de arranque. La tercera vía, sugerida por rickynils tras la publicación original, consiste en transformar el índice en un archivo .nix: la traslación JSON→Nix es directa y, en teoría, la pereza del evaluador Nix haría que importar un archivo enorme solo materialice el atributo consultado, sin frontera de parseo ni serialización intermedia. Cada método representa un equilibrio distinto entre seguridad, rendimiento y complejidad de integración.
Noticias agregadas con IA