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

• Lux ist ein neuer Paketmanager mit dem Ziel, ein für Lua geeignetes Ökosystem aufzubauen, und dient zur Erstellung, Wartung und Verteilung von Lua-Code
• Lux bietet eine einfache und intuitive CLI, inspiriert von bekannten Paketmanagern wie cargo

Funktionen

• Vollständige Portabilität zwischen Systemen
• Unterstützung für parallele Builds und Installationen 🚀
• Automatische Handhabung der Installation von Lua-Headern
• Freigabe der Lua-API über das lux-lib-Crate möglich
• Projektverwaltung über die Datei lux.toml
• Automatische Generierung von rockspecs
• Robuste Unterstützung für Lockfiles
• Vollständig reproduzierbare Builds und Entwicklungsumgebungen
• Integration von Code-Formatierung und Linting
• Unterstützung für das Ausführen von Tests über busted
• Neovim kann als Lua-Interpreter verwendet werden
• Reine Umgebungs-Konfiguration
• Kompatibel mit dem luarocks-Ökosystem

Motivation

Lua

• Luarocks blickt auf 20 Jahre Geschichte zurück und ist für die moderne Lua-Entwicklung nicht geeignet
• Lux zielt auf einen Neuanfang ab
  • Verwendung von TOML als primäres Manifestformat für die Abhängigkeitsverwaltung
  • Projekte können im Projektverzeichnis mit dem Befehl build gebaut und installiert werden
  • Erzwingt die Einhaltung von SemVer
  • Unterstützung für parallele Builds

Neovim

• Zunehmende Popularität durch den Neovim-Plugin-Manager rocks.nvim und die Luarocks-Unterstützung von lazy.nvim
• Lux ist nicht-destruktiv und greift nicht in die Verteilungsweise von Neovim-Plugins ein
• Mit dem Flag --nvim können Pakete in einer mit Neovim kompatiblen Baumstruktur installiert werden

Nix

• Wenn Neovim-Plugins als Luarocks-Pakete vorliegen, werden sie in nixpkgs verwendet
• lux.lock von Lux speichert die Quelle und den rockspec-Hash jeder Abhängigkeit

Nächste Schritte

• Fokus auf Bugfixes und die Verbesserung von Fehlermeldungen
• rocks.nvim soll auf Basis von Lux neu geschrieben werden
• Bei erfolgreicher Neuschreibung werden positive Auswirkungen auf das Neovim-Ökosystem erwartet

Dokumentation

• Tutorials und Leitfäden sind auf der Dokumentations-Website von Lux verfügbar
• Fragen und Probleme können über GitHub Discussions und den Issue-Tracker geklärt werden

Lizenz

• Lux wird unter der MIT-Lizenz bereitgestellt
• Das Lux-Logo wird unter der Lizenz CC BY-NC-SA 4.0 bereitgestellt

[GN⁺]

Hacker-News-Kommentare

• Die Runtime von Skriptsprachen ist ein Schwachpunkt. Ich nutze Neovim persönlich nicht, hatte aber das Gefühl, dass es die Weiterentwicklung von Lua fördern würde. Bryan Cantrill nannte Javascript einmal „LISP in C-Kleidung“. Bei Lua empfinde ich es als das Gegenteil, und genau deshalb mag ich Lua (zur Einordnung: Ich habe es nie beruflich eingesetzt).
  • Projekte wie Koreader verwenden Lua als primäre Anwendungssprache. Wenn man sie zu einem Umstieg bewegen könnte, würde das Vertrauen in die Reife und Popularität der Idee stärken.
• Ein interessantes Projekt. Ich würde gern zusammenarbeiten, um die Lua-Unterstützung in Pixi zu verbessern (über das conda-forge-Ökosystem). Wir paketieren bereits Lua und einige C-Erweiterungen. C-Erweiterungen sind ein Kernelement von Pixi, daher scheint das sehr gut zu passen.
  • pixi.sh (Dokumentation)
  • Lua-Paket im Registry: https://prefix.dev/channels/conda-forge/packages/lua
• Klingt großartig. Ich nutze Lua häufig, aber luarocks ist so meinungsstark, dass es fast nutzlos ist. Alles, was über „Installation von Bibliotheken zur direkten Ausführung auf dem lokalen System“ hinausgeht oder sich darum herum bewegt, scheitert schon am Anfang. Du hast eine eingebettete Scripting-Umgebung, die mit Lua-Paketen arbeitet, und möchtest Skripte dafür zusammen mit Abhängigkeiten paketieren? Dann kannst du es vergessen.
  • Ich weiß nicht, ob das für diesen Anwendungsfall besser ist, aber selbst wenn nicht, ist luarocks unbequem und frustrierend in der Nutzung.
• Persönlich habe ich bei jedem sprachspezifischen Paketmanager Vorbehalte. Ich habe das Gefühl, dass das nicht die richtige Richtung ist. Etwas wie nix scheint mir ein deutlich besserer Ansatz zu sein.
• Ein Paketmanager für Lua, der von Rust abhängt.
• Schön! Lua brauchte so etwas, um das Erstellen von Paketen zu vereinfachen.
• Schön. Ich wollte schon länger eine reproduzierbare Methode, um Lua-Pakete auf mehreren Geräten zu installieren.
• Warum wird für die Konfiguration nicht Lua statt TOML verwendet? Soweit ich mich erinnere, war Lua ursprünglich als Datenschemasprache gedacht, daher würde es gut passen.
• Danke, dass ihr das Neovim-Ökosystem wie einen First-Class-Citizen behandelt. Bei der Plugin-Entwicklung habe ich die einfache Nutzbarkeit von Drittanbieter-Bibliotheken wie Rust und Typescript vermisst.