Show HN : Lux - Un gestionnaire de paquets Lua avancé pour Lua

 (mrcjkb.dev)
2 points par GN⁺ 2025-04-09 | 1 commentaires | Partager sur WhatsApp
  • Lux est un nouveau gestionnaire de paquets qui réunit la création, la maintenance et le déploiement de code Lua dans une CLI simple, avec l’ambition d’apporter à l’écosystème Lua un flux de développement familier, à la cargo
  • Après un peu plus d’un an de développement, il a atteint un état très utilisable au quotidien, même si la prise en charge de MSVC, les messages d’erreur et certains cas limites restent à traiter avant la sortie 1.0
  • Il intègre un modèle de projet basé sur lux.toml, la génération automatique de rockspec, des lockfiles, les builds parallèles, l’installation des en-têtes Lua, ainsi que l’exécution du formatage, du linting et des tests dans un même flux
  • Tout en restant compatible avec l’écosystème Luarocks, il met l’accent sur la réduction du poids des anciennes contraintes de compatibilité, de l’imprévisibilité selon les systèmes, et de la lenteur des installations et de la synchronisation
  • Le déploiement de plugins Neovim et l’intégration Nix sont ses principaux cas d’usage, et la prochaine étape inclut la réécriture de rocks.nvim sur une base Lux plutôt que Luarocks

Le flux de gestion de paquets Lua proposé par Lux

  • Lux est un nouveau gestionnaire de paquets pour la création, la maintenance et le déploiement de code Lua
  • La CLI s’inspire de gestionnaires de paquets bien connus comme cargo de Rust
  • Il a désormais atteint un niveau « très utilisable au quotidien »
    • La prise en charge de MSVC, les messages d’erreur et certains cas limites restent encore à améliorer
    • Ces corrections font partie du plan de sortie de la version 1.0

Modèle de projet et intégration des outils de développement

  • Il prend en charge la portabilité entre systèmes, avec builds et installations en parallèle
  • Lux gère lui-même l’installation des en-têtes Lua
    • Sont pris en charge Lua 5.1, 5.2, 5.3, 5.4 et luajit
    • Les auteurs de paquets n’ont qu’à indiquer les versions de Lua compatibles
  • La crate lux-lib est entièrement embarquable et peut aussi être compilée pour exposer une API Lua
  • Il propose une notion de projet centrée sur le fichier lux.toml
    • Le rockspec est généré automatiquement à partir de lux.toml
    • Cela réduit la charge liée à la gestion manuelle de plusieurs fichiers rockspec dans un dépôt
  • Les lockfiles visent des builds et des environnements de développement reproductibles
    • Ils stockent les hashes des sources et des rockspecs
    • Ces hashes peuvent servir à faciliter l’intégration de Lux avec Nix
  • Le formatage et le linting du code sont également intégrés à la CLI
  • L’exécution de tests basés sur busted est prise en charge nativement
    • Neovim peut être utilisé comme interpréteur Lua
    • Un environnement pur est configuré

Différences avec Luarocks

  • Luarocks a un périmètre large, mais environ 20 ans de poids de compatibilité le rendent difficile à adapter au développement Lua moderne
  • Lux vise un nouveau départ et utilise TOML comme format de manifeste principal
    • La CLI permet d’ajouter, supprimer, figer et mettre à jour les dépendances
    • Dans un répertoire de projet contenant lux.toml, une commande comme build construit le projet et l’installe dans un arbre local au projet
    • Pendant le build, un lockfile des dépendances du projet est créé afin de pouvoir reproduire les mêmes dépendances sur des systèmes compatibles
  • Son approche pour encourager l’usage de SemVer est aussi différente
    • Luarocks autorise des versions arbitraires après le numéro de patch
    • Par exemple, 1.0.1.0.0.0.2 est valide dans Luarocks, mais est considéré comme dépourvu de sens utile
    • Lux le parse aussi, mais traite les valeurs après le numéro de patch comme des versions de prépublication
  • Les builds parallèles s’inspirent du Nix store
    • Lux hash le répertoire d’installation pour éviter les conflits entre paquets et permettre les builds parallèles sans risque de corruption du système de fichiers
    • Plus de détails sont disponibles dans le guide des conflits de paquets de Lux

Utilisation dans l’écosystème Neovim

  • Depuis la prise en charge de Luarocks par rocks.nvim et lazy.nvim, Luarocks gagne en popularité comme mode de distribution des plugins Neovim
  • L’usage existant de Luarocks reste toutefois limité par une portabilité incomplète et des résultats difficiles à prévoir selon les systèmes
  • Comme Luarocks est écrit en Lua, l’installation de nombreux paquets et la synchronisation du plugin rocks.nvim étaient très lentes
  • L’usage de Lux est non destructif et ne perturbe pas la distribution actuelle des plugins Neovim basée sur Git
  • Avec le flag --nvim, il installe les paquets dans une arborescence compatible avec les :h packages de Neovim

Lockfiles pour l’intégration avec Nix

  • Lorsqu’un plugin Neovim existe comme paquet Luarocks, nixpkgs l’utilise comme source de référence
    • En effet, dans un gestionnaire de paquets approprié, la responsabilité de déclarer les dépendances incombe à l’auteur du paquet
  • La prise en charge des lockfiles dans Luarocks est basique et n’inclut pas les hashes des sources
  • Luarocks comme Lux prennent en charge les dépendances en conflit via luarocks.loader
  • Pour nixpkgs, il est difficile d’ajouter proprement plusieurs versions d’une même dépendance dans un ensemble de paquets
  • Le fichier lux.lock de Lux stocke le hash de la source et le hash du rockspec de chaque dépendance
    • Si l’URL source est un dépôt Git, Lux stocke un NAR hash
    • lux.lock peut être utilisé, comme Cargo.lock, pour créer une fixed-output derivation incluant toutes les dépendances

Prochaines étapes et documentation

  • La priorité actuelle est la correction de bugs et l’amélioration des messages d’erreur
  • rocks.nvim doit être réécrit pour utiliser Lux en interne à la place de Luarocks
    • Cette réécriture vise à amener rocks.nvim à un niveau de performance comparable à celui des autres gestionnaires de plugins
    • Si elle réussit, elle montrera que Lux peut aussi être embarqué ailleurs
    • lazy.nvim, qui avait connu par le passé des problèmes liés à Luarocks, est cité comme exemple
  • Les premiers utilisateurs peuvent consulter les tutoriels et guides sur le site de documentation
  • Les questions et problèmes peuvent être remontés via les GitHub discussions ou l’issue tracker
  • Lux est sous licence LGPLv3.0+, et le logo Lux est sous licence © 2025 Kai Jakobi CC BY-NC-SA 4.0

À lire aussi

1 commentaires

 
GN⁺ 2025-04-09
Avis sur Hacker News

  • Le talon d’Achille des langages de script, c’est l’environnement d’exécution. Personnellement, je n’utilise pas Neovim, mais je pensais que son adoption allait pousser l’écosystème Lua à progresser dans ce domaine
    Bryan Cantrill a qualifié JavaScript de « LISP habillé en C » ; d’une certaine manière, Lua me donne l’impression inverse, et c’est pour ça que je l’aime. Cela dit, je n’ai jamais eu à l’utiliser au travail

    • Je ne vois pas sur quoi repose l’idée que JavaScript serait un Lisp habillé en C. Je ne vois pas non plus le rapport entre Lua et Lisp, et il n’a absolument pas de syntaxe Lisp

  • Je crois que des projets comme Koreader[1] utilisent Lua comme langage principal de l’application. Si l’on pouvait convaincre l’un de ces projets de migrer, cela donnerait une certaine confiance dans la maturité et la popularité de l’idée
    [1]: https://github.com/koreader/koreader

    • Bonne suggestion. Lux aura besoin d’un peu de temps pour mûrir, mais prendre en charge la compilation d’un grand projet multiplateforme comme koreader pourrait clairement être un bon objectif

  • Ça a vraiment l’air excellent. J’utilise beaucoup Lua, et luarocks était tellement orienté dans une direction précise qu’il était quasiment inutile pour ce dont j’avais besoin
    Dès qu’on s’éloigne un peu de « installer une bibliothèque à exécuter directement sur le système local », on est bloqué dès le départ. Si vous avez un environnement de scripting embarqué qui utilise des paquets Lua et que vous voulez distribuer vos scripts avec leurs dépendances, il fallait abandonner
    Je ne sais pas si cet outil est mieux adapté à cet usage, mais même si ce n’est pas le cas, luarocks est au mieux rugueux, et pénible à utiliser

    • La communauté Lua dépend énormément des bibliothèques C, et presque tous les paquets luarocks essaient de compiler une bibliothèque, ce qui les rend pratiquement inutilisables sous Windows

  • Projet intéressant. J’aimerais collaborer pour améliorer la prise en charge de Lua dans Pixi via l’écosystème conda-forge
    Nous empaquetons déjà lua et quelques extensions C. Les extensions C sont au cœur du périmètre de Pixi, donc cela pourrait bien s’accorder
    Documentation de pixi.sh et paquet lua dans le registre : https://prefix.dev/channels/conda-forge/packages/lua

    • Ça me semble une bonne idée. J’ai ouvert une issue dans le dépôt, n’hésite pas à me pinguer là-bas

  • Je pose la question parce que je ne le vois ni ici ni sur le site associé : je me demande s’il s’intègre nativement à package.path et package.cpath, s’il détecte les installations non standard mais largement utilisées comme brew(1), et s’il permet d’installer via le format GitHub :user/:repository
    Le projet a l’air chouette et bien réalisé

    • Les commandes lx run et lx lua définissent PATH, LUA_PATH et LUA_CPATH. Il existe aussi une commande lx path pour définir ces variables d’environnement
      La détection de l’installation de Lua utilise pkg-config par défaut et, si rien n’est trouvé, tente d’installer Lua via les crates lua_src et luajit_src. On pourra ajouter plus tard la prise en charge d’autres outils comme vcpkg
      L’installation GitHub :user/:repository n’est pas encore possible. C’est prévu pour lux.toml/les spécifications de dépendances, mais je n’autoriserai probablement pas la publication de rockspecs de ce type sur luarocks.org. Je ne veux pas inciter les gens à y publier des paquets qui ne peuvent pas être compilés avec luarocks

  • Donc on a un gestionnaire de paquets pour un langage conçu pour être embarqué dans C et fortement dépendant des bibliothèques C, écrit en Rust, et alors que Lua lui-même a été créé comme langage de configuration pour des programmes C, la configuration se fait en TOML
    Non merci. Luarocks a ses limites et devrait sans doute être réécrit, mais il faut utiliser un langage adapté à l’écosystème et suivre la culture de l’écosystème Lua. Rust et Cargo sont exactement à l’opposé de Lua

    • Lua a évolué et est aujourd’hui utilisé dans beaucoup plus de contextes que celui pour lequel il avait été créé au départ

  • Personnellement, j’en ai vraiment assez de ces gestionnaires de paquets propres à chaque langage. Ça ne me semble pas être la bonne direction ; une approche comme nix paraît bien meilleure

    • L’une des motivations de Lux est d’améliorer les écosystèmes Lua et Neovim dans nixpkgs

  • Un gestionnaire de paquets pour Lua qui dépend de Rust

    • Ça ne me semble pas poser de problème. La plupart des gestionnaires de paquets prennent en charge l’installation de paquets uniquement binaires
    • Tu pourrais être surpris de voir à quel point ça marche bien
    • Et en plus il utilise TOML

  • J’aime bien. Ça fait un bon moment que je voulais disposer d’un moyen d’avoir des installations reproductibles de paquets Lua sur plusieurs machines

    • J’ai réussi à obtenir des installations Lua reproductibles sur plusieurs machines, mais j’utilise surtout Lua de deux façons
      La première consiste à l’utiliser « brut », lié à une VM interne, et à gérer la base de code .lua comme une partie du build du projet. La seconde consiste à l’utiliser comme outil système, avec des outils comme luarocks --local et luaenv employés correctement dans des Makefile/CMakeLists.txt, avec un peu de luastatic pour les bundles de distribution
      Honnêtement, ce n’est pas très différent de Python ou d’un autre langage de script pouvant être embarqué. Il faut simplement toujours distinguer le /bin/script_language fourni par le système d’un langage utilisé comme outil de développement/moteur de scripting dans un projet plus vaste, ou comme outil pour un poste de travail local
      L’une des raisons pour lesquelles j’aime vraiment Lua, c’est qu’il est assez facile et amusant de packager des bibliothèques, de lier du bytecode et d’envelopper des bundles pour fournir aux utilisateurs du système d’exploitation cible une installation en un clic. Bien sûr, il faut quand même mettre un peu les mains dedans

  • C’est excellent, mais j’ai fortement l’impression que cela va à l’encontre de l’orientation de conception de Lua. Lua a été conçu comme un simple langage embarqué, où la « gestion de paquets » revient à télécharger et décompresser quelques zip, et où la « gestion de versions » consiste plus ou moins à choisir si l’on veut rester compatible 5.1 ou 5.4