Show HN: Lux - Un gestor avanzado de paquetes Lua para Lua

 (mrcjkb.dev)
2 puntos por GN⁺ 2025-04-09 | 1 comentarios | Compartir por WhatsApp
  • Lux es un nuevo gestor de paquetes que agrupa la creación, el mantenimiento y la distribución de código Lua en una CLI simple; busca llevar al ecosistema Lua un flujo de desarrollo familiar como el de cargo
  • Tras algo más de un año de desarrollo, llegó a un estado muy usable para el trabajo diario, aunque el soporte para MSVC, los mensajes de error y la cobertura de casos límite quedan como tareas pendientes antes del lanzamiento 1.0
  • Integra en un solo flujo un modelo de proyecto basado en lux.toml, generación automática de rockspec, lockfile, builds en paralelo, instalación de headers de Lua, formateo, linting y ejecución de tests
  • Mantiene la compatibilidad con el ecosistema de Luarocks, pero se enfoca en reducir la carga de compatibilidad heredada, la imprevisibilidad según el sistema y la experiencia lenta de instalación y sincronización
  • La distribución de plugins de Neovim y la integración con Nix son sus principales casos de uso; entre los próximos pasos está reescribir rocks.nvim sobre Lux en lugar de Luarocks

El flujo de gestión de paquetes Lua que ofrece Lux

  • Lux es un nuevo gestor de paquetes para la creación, mantenimiento y distribución de código Lua
  • La CLI está inspirada en gestores de paquetes conocidos como cargo de Rust
  • Actualmente alcanzó un nivel “muy usable para el trabajo diario”
    • Todavía quedan pendientes el soporte para MSVC, los mensajes de error y la cobertura de casos límite
    • Esas correcciones forman parte del plan para el lanzamiento 1.0

Modelo de proyecto e integración de herramientas de desarrollo

  • Soporta portabilidad entre sistemas y permite builds e instalaciones en paralelo
  • Lux se encarga de instalar los headers de Lua
    • Los objetivos soportados son Lua 5.1, 5.2, 5.3, 5.4 y luajit
    • Quienes escriben paquetes solo tienen que indicar las versiones de Lua compatibles
  • El crate lux-lib es completamente embebible y también puede compilarse para exponer una API Lua
  • Ofrece un concepto de proyecto centrado en el archivo lux.toml
    • Genera automáticamente el rockspec desde lux.toml
    • Reduce la carga de mantener manualmente varios archivos rockspec en el repositorio
  • El lockfile apunta a builds y entornos de desarrollo reproducibles
    • Guarda hashes de fuente y hashes de rockspec
    • Estos hashes pueden usarse para facilitar la integración de Lux con Nix
  • El formateo y el linting de código también están incluidos en la CLI
  • Soporta de forma nativa la ejecución de tests basados en busted
    • Puede usar Neovim como intérprete de Lua
    • Configura un entorno limpio

Diferencias con Luarocks

  • Luarocks tiene un alcance amplio, pero unos 20 años de carga de compatibilidad dificultan adaptarlo al desarrollo Lua moderno
  • Lux busca empezar de cero y usa TOML como formato principal de manifiesto
    • La CLI permite agregar, eliminar, fijar y actualizar dependencias
    • En un directorio de proyecto con lux.toml, comandos como build compilan el proyecto y lo instalan en un árbol local del proyecto
    • Durante el proceso de build, crea un lockfile de las dependencias del proyecto para poder reproducir las mismas dependencias en sistemas compatibles
  • También difiere en cómo fomenta el uso de SemVer
    • Luarocks permite versiones arbitrarias después de la versión de parche
    • Por ejemplo, 1.0.1.0.0.0.2 es válido en Luarocks, pero se considera que no tiene un significado útil
    • Lux también lo parsea, pero trata los valores posteriores a la versión de parche como una versión preliminar
  • Los builds en paralelo están inspirados en Nix store
    • Lux hashea los directorios de instalación para evitar conflictos entre paquetes y permitir builds en paralelo sin riesgo de dañar el sistema de archivos
    • Los detalles relacionados están en la guía de conflictos de paquetes de Lux

Uso en el ecosistema Neovim

  • Tras el soporte de Luarocks en rocks.nvim y lazy.nvim, Luarocks está ganando popularidad como forma de distribuir plugins de Neovim
  • Sin embargo, el uso actual de Luarocks carece de portabilidad completa y tiene la limitación de que los resultados pueden ser impredecibles según el sistema
  • Como Luarocks está escrito en Lua, la instalación de muchos paquetes y la sincronización de plugins de rocks.nvim eran muy lentas
  • El uso de Lux no es destructivo y no interfiere con el método actual de distribución de plugins de Neovim basado en Git
  • Al usar el flag --nvim, instala los paquetes en una estructura de árbol compatible con :h packages de Neovim

Lockfile para la integración con Nix

  • Cuando un plugin de Neovim existe como paquete de Luarocks, nixpkgs lo usa como fuente de referencia
    • Esto se debe a que, en un gestor de paquetes adecuado, la responsabilidad de declarar dependencias recae en quien escribe el paquete
  • El soporte de lockfile de Luarocks es básico y no incluye hashes de fuente
  • Tanto Luarocks como Lux soportan dependencias en conflicto mediante luarocks.loader
  • A nixpkgs le resulta difícil agregar razonablemente varias versiones de una misma dependencia al conjunto de paquetes
  • El lux.lock de Lux guarda el hash de fuente y el hash del rockspec de cada dependencia
    • Si la URL de fuente es un repositorio Git, Lux guarda un hash NAR
    • lux.lock puede usarse, como Cargo.lock, para crear una derivación de salida fija que incluya todas las dependencias

Próximos pasos y documentación

  • La prioridad actual es la corrección de bugs y la mejora de los mensajes de error
  • rocks.nvim será reescrito para usar Lux internamente en lugar de Luarocks
    • Esta reescritura busca llevar la velocidad de rocks.nvim al nivel de otros gestores de plugins
    • Si tiene éxito, servirá como ejemplo de que Lux puede embeberse en otros lugares
    • Como ejemplo se menciona lazy.nvim, que en el pasado tuvo problemas relacionados con Luarocks
  • Las personas que lo prueben al inicio pueden consultar tutoriales y guías en el sitio de documentación
  • Las preguntas o issues se reciben en GitHub discussions o en el issue tracker
  • Lux tiene licencia LGPLv3.0+, y el logo de Lux está bajo licencia CC BY-NC-SA 4.0 de © 2025 Kai Jakobi

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-04-09
Opiniones de Hacker News

  • El talón de Aquiles de los lenguajes de scripting es el entorno de ejecución. Personalmente no uso Neovim, pero pensé que la adopción de Neovim impulsaría avances en esta área para Lua.
    Bryan Cantrill llamó a JavaScript “LISP con ropa de C”, y en cierto sentido Lua me parece lo contrario, por eso me gusta. Aunque nunca me tocó usarlo en el trabajo.

    • No sé en qué se basan para decir que JavaScript es Lisp con ropa de C. Tampoco sé qué tiene que ver Lua con Lisp, y no tiene nada de sintaxis de Lisp.

  • Tengo entendido que proyectos como Koreader[1] usan Lua como lenguaje principal de la aplicación. Si pudieran convencer a uno de esos proyectos de migrar, eso daría cierta confianza sobre la madurez y popularidad de esta idea.
    [1]: https://github.com/koreader/koreader

    • Buena sugerencia. Probablemente Lux necesite algo de tiempo para madurar, pero compilar un proyecto grande y multiplataforma como koreader sin duda podría ser un buen objetivo.

  • Se ve realmente bien. Uso mucho Lua, y luarocks tenía una orientación tan marcada que era casi inútil para lo que necesitaba.
    Apenas te salías de “instalar bibliotecas para ejecutarlas directamente en el sistema local”, te topabas con una pared desde el inicio. Tenía un entorno de scripting embebido que usaba paquetes Lua, y si quería empaquetar y distribuir scripts junto con sus dependencias, había que rendirse.
    No sé si esta herramienta será mejor para ese caso, pero aunque no lo sea, luarocks, siendo generosos, es tosco y molesto de usar.

    • La comunidad de Lua depende muchísimo de bibliotecas en C, y casi todos los paquetes de luarocks intentan compilar una biblioteca, así que en Windows se vuelve prácticamente inútil.

  • Proyecto interesante. Me gustaría colaborar para crear un mejor soporte para Lua en Pixi a través del ecosistema conda-forge.
    Ya estamos empaquetando lua y algunas extensiones en C. Las extensiones en C son un área central de Pixi, así que creo que podría encajar bien.
    Documentación de pixi.sh y paquete lua en el registro: https://prefix.dev/channels/conda-forge/packages/lua

    • Me parece una buena idea. Abrí un issue en el repositorio, así que siéntete libre de hacer ping ahí.

  • Pregunto porque no lo vi aquí ni en los sitios relacionados: me interesa saber si se integra de forma nativa con package.path y package.cpath, si detecta instalaciones no estándar pero muy usadas como brew(1), y si se puede instalar con el formato de GitHub :user/:repository.
    El proyecto se ve genial y bien hecho.

    • Los comandos lx run y lx lua configuran PATH, LUA_PATH y LUA_CPATH. También hay un comando lx path para configurar esas variables de entorno.
      La detección de instalaciones de Lua usa pkg-config por defecto y, si no encuentra nada, intenta instalar Lua mediante los crates lua_src y luajit_src. Más adelante podríamos agregar soporte para otras herramientas como vcpkg.
      La instalación de GitHub con :user/:repository todavía no está disponible. Planeamos agregarla a lux.toml/la especificación de dependencias, pero probablemente no permitiremos publicar ese tipo de rockspec en luarocks.org. No queremos provocar que la gente suba paquetes que no se puedan compilar con luarocks.

  • ¿Entonces un gestor de paquetes para un lenguaje diseñado para embeberse en C y que depende mucho de bibliotecas en C está escrito en Rust, y aunque Lua en sí fue creado como lenguaje de configuración para programas en C, la configuración se hace en TOML?
    Paso. Luarocks tiene limitaciones y probablemente habría que reescribirlo, pero debería usarse un lenguaje que encaje con el ecosistema y seguir la cultura del ecosistema Lua. Rust y Cargo están exactamente en el extremo opuesto de Lua.

    • Lua ha evolucionado y se usa en muchos más lugares que el propósito para el que fue creado originalmente.

  • Personalmente estoy harto de estos gestores de paquetes específicos de cada lenguaje. No se siente como el camino correcto; un enfoque como nix me parece mucho mejor.

    • Una de las motivaciones de Lux es mejorar los ecosistemas de Lua y Neovim en nixpkgs.

  • Un gestor de paquetes para Lua que depende de Rust.

    • No parece un gran problema. La mayoría de los gestores de paquetes soportan la instalación de paquetes solo binarios.
    • Puede que te sorprenda lo bien que funciona.
    • Y además usa TOML.

  • Me gusta. Desde hace bastante quería tener una forma de hacer instalaciones reproducibles de paquetes Lua en varias máquinas.

    • He logrado tener estados reproducibles de instalación de paquetes Lua en varias máquinas, pero uso Lua principalmente de dos maneras.
      Una es en forma “cruda”, vinculándolo a una VM interna y gestionando la base de código .lua como parte de la compilación del proyecto; la otra es como herramienta del sistema, usando de manera adecuada luarocks --local, herramientas como luaenv, integrándolo en Makefile/CMakeLists.txt y mezclando un poco de luastatic para los bundles de distribución.
      Sinceramente, esto no es muy distinto de Python u otros lenguajes de scripting que pueden ir incluidos. Lo importante es distinguir siempre entre el /bin/script_language que provee el sistema y el lenguaje usado como herramienta de desarrollo/motor de scripting dentro de un proyecto más grande, o como herramienta para el entorno local de trabajo.
      Una de las razones por las que me gusta tanto Lua es que empaquetar bibliotecas, enlazar bytecode, envolver bundles y entregarlos a usuarios del sistema operativo objetivo como una instalación de un clic es bastante fácil y divertido. Claro, requiere algo de trabajo manual.

  • Es excelente, pero da una fuerte impresión de ir en contra de la dirección de diseño de Lua. Lua fue diseñado como un lenguaje simple para embeber, y aquí “gestión de paquetes” se parece más a descargar y descomprimir algunos zips, mientras que “gestión de versiones” es básicamente elegir si quieres compatibilidad con 5.1 o con 5.4.