Show HN: Lux – ein fortschrittlicher Lua-Paketmanager für Lua

 (mrcjkb.dev)
2 Punkte von GN⁺ 2025-04-09 | 1 Kommentare | Auf WhatsApp teilen
  • Lux ist ein neuer Paketmanager, der das Erstellen, Pflegen und Verteilen von Lua-Code in einer einfachen CLI bündelt und einen vertrauten Entwicklungsablauf wie bei cargo ins Lua-Ökosystem bringen soll
  • Nach etwas mehr als einem Jahr Entwicklung hat er einen Zustand erreicht, in dem er für die tägliche Arbeit sehr gut nutzbar ist; MSVC-Unterstützung, Fehlermeldungen und die Behandlung von Edge Cases bleiben jedoch Aufgaben vor dem 1.0-Release
  • Er integriert ein Projektmodell auf Basis von lux.toml, automatische rockspec-Erzeugung, Lockfiles, parallele Builds, die Installation von Lua-Headern sowie Formatierung, Linting und Testausführung in einem durchgängigen Ablauf
  • Bei gleichzeitiger Kompatibilität mit dem Luarocks-Ökosystem liegt der Fokus darauf, alte Kompatibilitätslasten, systemspezifische Unvorhersehbarkeit sowie langsame Installations- und Synchronisierungserfahrungen zu reduzieren
  • Wichtige Einsatzbereiche sind die Verteilung von Neovim-Plugins und die Nix-Integration; zu den nächsten Schritten gehört, rocks.nvim auf Basis von Lux statt Luarocks neu zu schreiben

Der von Lux bereitgestellte Lua-Paketmanagement-Workflow

  • Lux ist ein neuer Paketmanager für das Erstellen, Pflegen und Verteilen von Lua-Code
  • Die CLI ist von bekannten Paketmanagern wie Rusts cargo inspiriert
  • Der aktuelle Stand ist „für die tägliche Arbeit sehr gut nutzbar“
    • MSVC-Unterstützung, Fehlermeldungen und die Behandlung von Edge Cases stehen noch aus
    • Diese Korrekturen sind für den 1.0-Release geplant

Projektmodell und Integration von Entwicklungstools

  • Unterstützt Portabilität zwischen Systemen und ermöglicht parallele Builds sowie parallele Installationen
  • Lux übernimmt die Installation von Lua-Headern
    • Unterstützt werden Lua 5.1, 5.2, 5.3, 5.4 und luajit
    • Paketautoren müssen nur die kompatiblen Lua-Versionen angeben
  • Das lux-lib-Crate ist vollständig einbettbar und kann auch so gebaut werden, dass es eine Lua-API bereitstellt
  • Bietet ein Projektkonzept rund um die Datei lux.toml
    • Aus lux.toml werden rockspecs automatisch erzeugt
    • Der Aufwand, mehrere rockspec-Dateien direkt im Repository zu pflegen, wird reduziert
  • Lockfiles zielen auf reproduzierbare Builds und Entwicklungsumgebungen ab
    • Sie speichern Source-Hashes und rockspec-Hashes
    • Diese Hashes können genutzt werden, um Lux leichter mit Nix zu integrieren
  • Codeformatierung und Linting sind ebenfalls in der CLI enthalten
  • Testausführung auf Basis von busted wird standardmäßig unterstützt
    • Neovim kann als Lua-Interpreter verwendet werden
    • Es wird eine saubere Umgebung eingerichtet

Unterschiede zu Luarocks

  • Luarocks hat einen großen Funktionsumfang, lässt sich wegen der Kompatibilitätslast aus rund 20 Jahren aber nur schwer an moderne Lua-Entwicklung anpassen
  • Lux will einen Neustart ermöglichen und verwendet TOML als primäres Manifestformat
    • Abhängigkeiten können per CLI hinzugefügt, entfernt, fixiert und aktualisiert werden
    • In einem Projektverzeichnis mit lux.toml bauen Befehle wie build das Projekt und installieren es in einem projektlokalen Tree
    • Während des Builds wird ein Lockfile der Projektabhängigkeiten erstellt, sodass sich dieselben Abhängigkeiten auf kompatiblen Systemen reproduzieren lassen
  • Auch die Förderung der Nutzung von SemVer unterscheidet sich
    • Luarocks erlaubt beliebige Versionsteile nach der Patch-Version
    • Zum Beispiel ist 1.0.1.0.0.0.2 in Luarocks gültig, wird aber als semantisch wenig nützlich angesehen
    • Lux parst dies ebenfalls, behandelt Werte nach der Patch-Version jedoch als Prerelease-Version
  • Parallele Builds sind vom Nix Store inspiriert
    • Lux hasht Installationsverzeichnisse, um Paketkonflikte zu verhindern und parallele Builds ohne Risiko einer Beschädigung des Dateisystems zu ermöglichen
    • Weitere Details stehen im Leitfaden zu Paketkonflikten von Lux

Nutzung im Neovim-Ökosystem

  • Seit der Luarocks-Unterstützung von rocks.nvim und lazy.nvim gewinnt Luarocks als Distributionsweg für Neovim-Plugins an Popularität
  • Die bisherige Nutzung von Luarocks ist jedoch durch fehlende vollständige Portabilität und schwer vorhersehbare Ergebnisse je nach System eingeschränkt
  • Da Luarocks in Lua geschrieben ist, waren die Installation vieler Pakete und die Synchronisierung von rocks.nvim-Plugins sehr langsam
  • Der Einsatz von Lux ist nicht destruktiv und stört die derzeitige Git-basierte Verteilung von Neovim-Plugins nicht
  • Mit dem Flag --nvim werden Pakete in einer Tree-Struktur installiert, die mit Neovims :h packages kompatibel ist

Lockfiles für die Nix-Integration

  • Wenn ein Neovim-Plugin als Luarocks-Paket vorliegt, verwendet nixpkgs dieses als maßgebliche Quelle
    • Denn bei einem geeigneten Paketmanager liegt die Verantwortung für die Deklaration von Abhängigkeiten beim Paketautor
  • Die Lockfile-Unterstützung von Luarocks ist grundlegend und enthält keine Source-Hashes
  • Sowohl Luarocks als auch Lux unterstützen über luarocks.loader kollidierende Abhängigkeiten
  • Für nixpkgs ist es schwierig, mehrere Versionen derselben Abhängigkeit sinnvoll in ein Paketset aufzunehmen
  • Lux’ lux.lock speichert für jede Abhängigkeit den Source-Hash und den rockspec-Hash
    • Wenn die Source-URL ein Git-Repository ist, speichert Lux einen NAR hash
    • lux.lock kann verwendet werden, um eine fixed-output derivation mit allen Abhängigkeiten zu erstellen, ähnlich wie Cargo.lock

Nächste Schritte und Dokumentation

  • Aktuelle Priorität haben Bugfixes und bessere Fehlermeldungen
  • rocks.nvim soll so umgeschrieben werden, dass es intern Lux statt Luarocks verwendet
    • Diese Neufassung soll die Geschwindigkeit von rocks.nvim auf das Niveau anderer Plugin-Manager bringen
    • Bei Erfolg wäre sie ein Beispiel dafür, dass Lux auch anderswo eingebettet werden kann
    • Als Beispiel wird lazy.nvim genannt, das in der Vergangenheit Probleme im Zusammenhang mit Luarocks hatte
  • Frühe Nutzer finden Tutorials und Leitfäden auf der Dokumentationsseite
  • Fragen oder Issues können über GitHub Discussions oder den Issue Tracker eingereicht werden
  • Lux steht unter der Lizenz LGPLv3.0+, und das Lux-Logo ist © 2025 Kai Jakobi unter der Lizenz CC BY-NC-SA 4.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-09
Hacker-News-Kommentare

  • Die Achillesferse von Skriptsprachen ist die Laufzeitumgebung. Ich persönlich nutze Neovim nicht, aber ich hatte den Eindruck, dass die Verbreitung von Neovim in der Lua-Welt Fortschritte in diesem Bereich vorantreiben könnte.
    Bryan Cantrill nannte JavaScript einmal „LISP in C-Kleidung“; in gewisser Hinsicht fühlt sich Lua für mich wie das Gegenteil davon an, und das gefällt mir. Allerdings musste ich es beruflich noch nie einsetzen.

    • Ich weiß nicht, worauf die Aussage beruht, JavaScript sei Lisp in C-Kleidung. Und ich weiß auch nicht, was Lua mit Lisp zu tun haben soll; Lisp-Syntax hat es jedenfalls überhaupt nicht.

  • Soweit ich weiß, verwenden Projekte wie Koreader[1] Lua als primäre Anwendungssprache. Wenn man eines dieser Projekte zu einem Wechsel bewegen könnte, würde das sicher ein gewisses Vertrauen in Reife und Popularität dieser Idee schaffen.
    [1]: https://github.com/koreader/koreader

    • Guter Vorschlag. Lux wird noch etwas Zeit brauchen, um auszureifen, aber ein großes Multiplattform-Projekt wie koreader zu bauen, könnte definitiv ein gutes Ziel sein.

  • Sieht wirklich gut aus. Ich nutze viel Lua, aber luarocks war für das, was ich brauchte, fast unbrauchbar, weil es eine zu starke eigene Ausrichtung hat.
    Sobald man auch nur ein wenig über „Bibliotheken installieren, die direkt auf dem lokalen System ausgeführt werden“ hinausgeht, steckt man von Anfang an fest. Wenn man eine eingebettete Scripting-Umgebung hat, die Lua-Pakete nutzt, und Skripte samt Abhängigkeiten bündeln und ausliefern möchte, musste man praktisch aufgeben.
    Ich weiß nicht, ob dieses Tool für diesen Zweck besser ist, aber selbst wenn nicht: luarocks ist im besten Fall sperrig und nervig zu benutzen.

    • Die Lua-Community ist extrem stark von C-Bibliotheken abhängig, und fast jedes luarocks-Paket versucht, eine Bibliothek zu bauen, was es unter Windows praktisch unbrauchbar macht.

  • Interessantes Projekt. Ich würde gern zusammenarbeiten, um über das conda-forge-Ökosystem in Pixi besseren Lua-Support zu schaffen.
    Wir paketieren bereits lua und einige C-Erweiterungen. C-Erweiterungen sind ein Kernbereich von Pixi, daher könnte das gut passen.
    Die pixi.sh-Dokumentation und das lua-Paket in der Registry: https://prefix.dev/channels/conda-forge/packages/lua

    • Klingt nach einer guten Idee. Ich habe im Repository ein Issue eröffnet; du kannst mich dort gern anpingen.

  • Da ich es hier oder auf den zugehörigen Seiten nicht gesehen habe, frage ich: Integriert es sich nativ in package.path und package.cpath, erkennt es nicht standardmäßige, aber weit verbreitete Installationen wie brew(1), und kann man per GitHub-user/:repository-Schema installieren?
    Das Projekt sieht cool und gut gemacht aus.

    • Die Befehle lx run und lx lua setzen PATH, LUA_PATH und LUA_CPATH. Außerdem gibt es den Befehl lx path, um diese Umgebungsvariablen zu setzen.
      Die Erkennung von Lua-Installationen nutzt standardmäßig pkg-config; wenn nichts gefunden wird, wird versucht, Lua über die Crates lua_src und luajit_src zu installieren. Unterstützung für andere Tools wie vcpkg könnte später hinzukommen.
      GitHub-Installationen im Stil :user/:repository gehen noch nicht. Ich plane, das zu lux.toml bzw. zur Abhängigkeitsdefinition hinzuzufügen, werde aber wohl nicht erlauben, solche rockspecs auf luarocks.org zu veröffentlichen. Ich möchte nicht dazu beitragen, dass Leute Pakete hochladen, die sich mit luarocks nicht bauen lassen.

  • Ein Paketmanager für eine Sprache, die dafür entworfen wurde, in C eingebettet zu werden und stark von C-Bibliotheken abhängt, wird in Rust geschrieben; und Lua selbst wurde als Konfigurationssprache für C-Programme geschaffen, aber die Konfiguration erfolgt in TOML?
    Nein danke. Luarocks hat Grenzen und sollte vermutlich neu geschrieben werden, aber man sollte eine Sprache verwenden, die zum Ökosystem passt, und der Kultur des Lua-Ökosystems folgen. Rust und Cargo stehen Lua diametral gegenüber.

    • Lua hat sich weiterentwickelt und wird heute für viel mehr eingesetzt als für den ursprünglichen Zweck, für den es geschaffen wurde.

  • Ich persönlich bin diese sprachspezifischen Paketmanager ziemlich leid. Es fühlt sich nicht nach der richtigen Richtung an; ein Ansatz wie nix wirkt deutlich besser.

    • Eine der Motivationen für Lux ist, das Lua- und Neovim-Ökosystem in nixpkgs zu verbessern.

  • Ein Paketmanager für Lua, der von Rust abhängt.

    • Klingt für mich nicht nach einem großen Problem. Die meisten Paketmanager unterstützen die Installation von reinen Binärpaketen.
    • Du wärst vielleicht überrascht, wie gut das funktioniert.
    • Und dazu noch TOML.

  • Gefällt mir. Ich wollte schon seit geraumer Zeit eine Möglichkeit für reproduzierbare Lua-Paketinstallationen auf mehreren Maschinen haben.

    • Ich habe zwar reproduzierbare Lua-Paketinstallationen auf mehreren Maschinen hinbekommen, aber ich nutze Lua hauptsächlich auf zwei Arten:
      einmal „roh“, indem ich es in eine interne VM linke und die .lua-Codebasis als Teil des Projekt-Builds verwalte; und einmal als System-Tool, wobei ich luarocks --local, luaenv und ähnliche Werkzeuge passend einsetze, sie in Makefile/CMakeLists.txt integriere und für Distributions-Bundles noch etwas luastatic dazumische.
      Ehrlich gesagt unterscheidet sich das nicht wesentlich von Python oder anderen Skriptsprachen, die mitgeliefert werden können. Man muss nur immer zwischen dem vom System bereitgestellten /bin/script_language und einer Sprache unterscheiden, die innerhalb eines größeren Projekts als Entwicklungswerkzeug/Scripting-Engine oder als Tool für den lokalen Arbeitsplatz dient.
      Einer der Gründe, warum ich Lua wirklich mag, ist, dass es ziemlich einfach und unterhaltsam ist, Bibliotheken zu paketieren, Bytecode zu linken und Bundles zu schnüren, die man Nutzern des Zielbetriebssystems als Ein-Klick-Installation bereitstellen kann. Natürlich muss man dafür schon ein bisschen selbst Hand anlegen.

  • Es ist zwar großartig, aber es fühlt sich stark so an, als gehe es gegen die Designrichtung von Lua. Lua wurde als einfache Einbettungssprache entworfen; „Paketverwaltung“ bedeutet hier eher, ein paar ZIP-Dateien herunterzuladen und zu entpacken, und „Versionsverwaltung“ eher, zu wählen, ob man 5.1-kompatibel oder 5.4-kompatibel arbeiten will.