El ecosistema: LuaRocks y el criterio de dependencia

Un lenguaje con biblioteca estándar pequeña traslada al programador una decisión que otros toman por él: qué código ajeno entra en el proceso. En Lua esa decisión se toma varias veces por proyecto y casi siempre sin método, lo que explica que dos programas equivalentes puedan no compartir ni una dependencia. Sin embargo el ecosistema no es un caos: hay un conjunto reducido de bibliotecas que aparecen una y otra vez, un gestor de paquetes con un modelo peculiar y limitaciones reales, y una práctica cultural —copiar el fichero dentro del proyecto— que en Lua es respetable y en otros lenguajes sería una herejía. Esta lección cierra el nivel con lo que la biblioteca estándar no puede darte: criterio.

Las bibliotecas que todo el mundo acaba usando

El ecosistema tiene un centro sorprendentemente estable. Estas son las piezas que aparecen en la inmensa mayoría de los proyectos serios, agrupadas por el hueco que tapan.

A esa lista hay que sumar los analizadores de JSON, que son el caso paradigmático de la fragmentación: uno escrito en C con prioridad en la velocidad, otro en Lua puro para máxima portabilidad, otro pensado para no perder el orden de las claves. Ninguno es el oficial, y los tres representan a un valor ausente y a una tabla vacía de maneras incompatibles entre sí. También conviene conocer Penlight, que es un intento explícito de suministrar la biblioteca estándar grande que Lua no tiene, y cuya adopción divide al ecosistema precisamente por eso.

LuaRocks: el gestor y sus límites

LuaRocks es el gestor de paquetes del ecosistema. Su unidad es la especificación de paquete, un fichero que es a la vez descripción y programa Lua: declara nombre, versión, dependencias con restricciones, licencia y el procedimiento de construcción. Ese procedimiento puede ser una simple copia de ficheros, una llamada a un sistema de construcción o la compilación de un módulo en C.

Los paquetes se instalan en un árbol. Hay un árbol del sistema, uno por usuario y, lo importante para un proyecto serio, uno local en el propio directorio de trabajo.

luarocks init                 # crea un arbol local y un envoltorio del interprete
luarocks install lpeg         # instala en ese arbol, sin tocar el sistema
luarocks install busted --local
luarocks list
luarocks show lpeg

-- Las rutas de busqueda son datos ordinarios y se pueden inspeccionar
print(package.path)   -- donde se buscan los modulos en Lua
print(package.cpath)  -- donde se buscan los modulos en C

El modelo funciona, pero tiene tres limitaciones estructurales que conviene conocer antes de apoyarse en él.

La primera es la multiplicidad de versiones del lenguaje. Un paquete no se instala para Lua a secas, sino para una versión concreta, y el ecosistema real está repartido entre 5.1, 5.4 y LuaJIT, que declara compatibilidad con 5.1. Un mismo paquete puede existir, no existir o comportarse distinto según cuál uses, y los módulos escritos en C hay que compilarlos por separado para cada una.

La segunda es la compilación. En cuanto una dependencia contiene C, instalarla exige un compilador, las cabeceras de desarrollo del intérprete y, con frecuencia, las cabeceras de una biblioteca del sistema. Eso convierte una instalación trivial en una máquina de desarrollo en un problema real dentro de un contenedor mínimo o en una plataforma sin herramientas.

La tercera es la reproducibilidad. LuaRocks no fija por defecto el conjunto exacto de versiones instaladas de la forma en que lo hacen los ficheros de bloqueo de otros ecosistemas, de modo que dos instalaciones separadas en el tiempo pueden traer árboles de dependencias distintos si la especificación no pinta las versiones con precisión.

flowchart TD
A[Necesito una funcionalidad] --> B[La ofrece el programa anfitrion]
B -->|si| C[Usar la del anfitrion y no depender]
B -->|no| D[Esta en la biblioteca estandar]
D -->|si| C
D -->|no| E[Puedo escribirlo en menos de cien lineas]
E -->|si| F[Escribirlo y ser duenos del codigo]
E -->|no| G[Existe una biblioteca de referencia clara]
G -->|no| F
G -->|si| H[Es Lua puro y de un solo fichero]
H -->|si| I[Copiarla dentro del proyecto y fijar version]
H -->|no| J[Depender via LuaRocks y fijar version exacta]

Criterio para elegir una dependencia

En un lenguaje sin biblioteca grande, elegir bien es una habilidad técnica, no una cuestión de gusto. Estas son las preguntas que conviene hacerse, ordenadas por poder de descarte.

La primera es si la dependencia es de Lua puro o contiene C. Una dependencia de Lua puro se instala copiando ficheros, funciona en cualquier plataforma donde funcione el intérprete y se puede interiorizar en el proyecto. Una dependencia con C es más rápida y a menudo insustituible, pero introduce un requisito de construcción que se propagará a todos los que usen tu código.

La segunda es cuántas dependencias transitivas arrastra. En Lua la respuesta sana suele ser cero o una; un paquete que trae doce está importando una filosofía distinta de la del lenguaje.

La tercera, y la más específica de esta cultura, es si puedes leer su código fuente entero en una tarde. Una parte enorme del ecosistema son ficheros de doscientas a quinientas líneas de Lua legible. Leerlas antes de adoptarlas es factible, y cambia por completo la naturaleza de la relación: dejas de depender de una caja negra y pasas a usar código que entiendes.

La cuarta es la compatibilidad de versiones declarada, con las cuatro variantes que importan, y la quinta es la salud del mantenimiento: fecha del último cambio, número de personas con permiso de publicación, presencia de pruebas y de licencia explícita.

Existe además una prueba práctica que descarta más candidatos que todas las anteriores juntas: cargar la biblioteca y mirar qué deja detrás. Una dependencia sana define un módulo y devuelve una tabla. Una dependencia mal educada escribe en el entorno global, sustituye funciones de la biblioteca estándar o parchea metatablas compartidas, y esos efectos son invisibles hasta que rompen algo remoto.

-- Detectar globales nuevos creados al cargar un modulo
local antes = {}
for k in pairs(_G) do antes[k] = true end

local m = require("candidata")

for k in pairs(_G) do
  if not antes[k] then print("global nuevo:", k) end
end
print("devuelve:", type(m))   -- lo sano es table o function

Depender, copiar o escribir

La práctica de copiar un módulo dentro del propio proyecto está mal vista en muchos ecosistemas y en Lua es no solo aceptable sino frecuentemente la decisión correcta. La razón es de proporciones: cuando la dependencia es un fichero de trescientas líneas que puedes leer, revisar y probar, mantener un gestor de paquetes, un árbol de instalación y un procedimiento de despliegue para administrarla es más complejo que el propio código que administra.

-- Un proyecto que interioriza sus dependencias pequenas
-- proyecto/
--   init.lua
--   vendor/json.lua      -- copiado, con version y licencia anotadas arriba
--   vendor/inspect.lua

local json = require("proyecto.vendor.json")

La disciplina que hace legítima esta práctica cabe en cuatro reglas. Anota en la cabecera del fichero copiado su origen, su versión exacta y su licencia. No lo modifiques salvo que sea imprescindible, y si lo haces, deja constancia del cambio en el mismo sitio. Escríbele pruebas propias, porque a partir de ese momento el código es tuyo. Y revisa periódicamente si el original corrigió algo que te afecta.

La tercera vía es escribirlo. En un lenguaje cuyas primitivas de tabla, cadena y función son tan expresivas, una cantidad sorprendente de necesidades comunes se resuelve en menos de cien líneas: una copia profunda, una división de cadenas, una cola, un conjunto, una caché de tamaño acotado, un serializador para el subconjunto de datos que tu programa realmente maneja. Escribir esas cien líneas suele salir más barato a medio plazo que negociar la interfaz, las suposiciones y el ciclo de vida de una biblioteca ajena que resuelve además veinte casos que no tienes.