Show HN : Lux – un gestionnaire de paquets avancé pour Lua

• Lux est un nouveau gestionnaire de paquets visant à construire un écosystème adapté à Lua, pour créer, maintenir et déployer du code Lua
• Lux propose une CLI simple et intuitive, inspirée de gestionnaires de paquets bien connus comme cargo

Fonctionnalités

• Portabilité complète entre systèmes
• Prise en charge des builds et des installations en parallèle 🚀
• Gestion automatique de l’installation des en-têtes Lua
• Exposition possible de l’API Lua via le crate lux-lib
• Gestion de projet via le fichier lux.toml
• Génération automatique de rockspec
• Prise en charge robuste des lockfiles
• Builds et environnements de développement entièrement reproductibles
• Intégration du formatage de code et du linting
• Prise en charge de l’exécution des tests avec busted
• Possibilité d’utiliser Neovim comme interpréteur Lua
• Configuration d’environnements purs
• Compatible avec l’écosystème luarocks

Motivation

Lua

• Luarocks a 20 ans d’histoire et n’est pas adapté au développement Lua moderne
• Lux vise à offrir un nouveau départ
  • Utilisation de TOML comme format principal de manifeste pour la gestion des dépendances
  • Possibilité de builder et d’installer un projet depuis le répertoire du projet avec la commande build
  • Respect de SemVer imposé
  • Prise en charge des builds parallèles

Neovim

• Popularité croissante grâce au gestionnaire de plugins Neovim rocks.nvim et à la prise en charge de Luarocks par lazy.nvim
• Lux est non destructif et n’interfère pas avec la manière dont les plugins Neovim sont distribués
• Le flag --nvim permet d’installer les paquets dans une arborescence compatible avec Neovim

Nix

• Lorsque des plugins Neovim existent sous forme de paquets Luarocks, nixpkgs les utilise
• Le lux.lock de Lux stocke la source et le hash du rockspec de chaque dépendance

Étapes suivantes

• Se concentrer sur les corrections de bugs et l’amélioration des messages d’erreur
• Réécriture prévue de rocks.nvim sur la base de Lux
• En cas de réécriture réussie, impact positif attendu sur l’écosystème Neovim

Documentation

• Tutoriels et guides disponibles sur le site de documentation de Lux
• Questions et résolution de problèmes possibles via les discussions GitHub et l’issue tracker

Licence

• Lux est proposé sous licence MIT
• Le logo Lux est proposé sous licence CC BY-NC-SA 4.0

[GN⁺]

Commentaire Hacker News

• Les environnements d’exécution des langages de script sont un point faible. Je n’utilise pas Neovim personnellement, mais j’ai toujours eu le sentiment que cela contribuerait à faire progresser Lua. Bryan Cantrill a qualifié Javascript de « LISP habillé en C ». Avec Lua, j’ai l’impression que c’est l’inverse, et c’est pour cela que j’aime Lua (à noter : je ne l’ai jamais utilisé dans le cadre du travail)
  • Des projets comme Koreader utilisent Lua comme langage principal de l’application. Si vous pouvez les convaincre de migrer, cela donnerait confiance dans la maturité de l’idée et dans sa popularité
• Projet intéressant. J’aimerais collaborer pour améliorer le support 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 de Pixi, donc cela semble bien correspondre
  • pixi.sh (documentation)
  • Package lua dans le registre : https://prefix.dev/channels/conda-forge/packages/lua
• Ça a l’air formidable. J’utilise beaucoup Lua, mais luarocks est tellement prescriptif qu’il est presque inutilisable. Tout ce qui va au-delà de « installer une bibliothèque pour l’exécuter directement sur le système local », ou même autour de cela, devient impossible à démarrer. Vous avez un environnement de scripting intégré qui fonctionne avec des packages Lua, et vous voulez empaqueter les scripts à utiliser là-dedans avec leurs dépendances ? Il faut abandonner
  • Je ne sais pas si c’est meilleur pour ce cas d’usage, mais même si ce n’est pas le cas, luarocks reste pénible et frustrant à utiliser
• Personnellement, je me méfie de tous les gestionnaires de paquets spécifiques à un langage. J’ai l’impression que ce n’est pas la bonne direction. Quelque chose comme nix me semble une approche bien meilleure
• Un gestionnaire de paquets pour Lua qui dépend de Rust
• Bien ! Lua avait besoin de quelque chose comme ça pour rendre les packages plus faciles à créer
• Bien. Je voulais une manière reproductible d’installer des packages Lua sur plusieurs appareils
• Pourquoi ne pas utiliser Lua pour la configuration au lieu de TOML ? Si je me souviens bien, Lua était à l’origine un langage de schéma de données, donc cela semblerait approprié
• Merci de traiter l’écosystème Neovim comme un citoyen de première classe. Pendant le développement de plugins, la facilité d’utilisation de bibliothèques tierces comme Rust et Typescript m’a manqué