Show HN: Lux – A luxurious package manager for Lua

Original Article ↗ Hacker News Discussion ↗

Integration and Lua Version Management

  • Lux commands (lx run, lx lua, lx path) set PATH, LUA_PATH, and LUA_CPATH; it can detect Lua/LuaJIT via pkg-config or build them via Rust crates if missing.
  • Some argue strongly that good Lua package management should not depend on system Lua, but instead always bundle its own local Lua tree for reproducibility and shipping; system detection is seen as repeating past mistakes.
  • Others counter that pkg-config with version checks is fine, can be made reproducible (e.g., via Nix-style setups), and Lux can also just install the required Lua itself.
  • Lux supports multiple versions simultaneously and handles diamond dependencies via a lux.loader that consults the lockfile.

Relationship to LuaRocks and Existing Tooling

  • Several users find LuaRocks confusing or fragile, especially around C libraries and multi-version Lua setups; on Windows it’s described as “basically unusable” due to build failures.
  • Others defend LuaRocks as easy once --local is embraced and praise its role in fully local, shippable bundles.
  • Some say most people don’t use LuaRocks anyway; others report reproducible setups with luaenv + LuaRocks + CMake.
  • Lux is welcomed as potentially more intuitive, especially for Neovim plugin development and cross-machine reproducibility.

Config Format: TOML vs Lua

  • A major thread debates using lux.toml instead of Lua scripts.
  • Pro-TOML arguments:
    • Prefer declarative, non-Turing-complete manifests (rule of least power).
    • Avoid halting-problem and runtime variability in configs.
    • Makes it feasible for lx add … and similar commands to reliably modify manifests.
  • Pro-Lua arguments:
    • Lua was designed as a configuration language; using TOML is seen as aesthetically and culturally off.
    • Lua configs could be sandboxed or restricted to a declarative subset.
    • Examples from other ecosystems show executable configs can work.
  • Some cite Python’s long experience with executable manifests as a cautionary tale; others mention Zig/Nix as nuanced counterexamples.

Lua Ecosystem and Use Cases

  • Low “batteries included” standard library is cited as a reason for Lua’s limited general adoption; others say this is by design for an embeddable language and that a community stdlib might be appropriate.
  • As a Bash replacement, opinions are mixed:
    • Pros: extremely fast startup, good for text processing, can replace many small Unix tools.
    • Cons: weak stdlib, frequent need to “reinvent the wheel,” especially without well-designed host APIs.
  • Some see Lux as helpful for Neovim, Roblox-like, and embedded scripting scenarios; others think it pushes Lua toward a heavier, Cargo-style ecosystem contrary to its minimalist, C-centric roots.

Implementation Choices and Ecosystem Fit

  • Lux is written in Rust, uses TOML, and leans on Rust crates for Lua/LuaJIT integration; some praise the practicality, others feel this clashes with Lua’s culture.
  • There is interest in integrating Lux with Nix/pixi/conda-forge to improve packaging of Lua and C extensions.
  • A few commenters are tired of language-specific package managers and prefer global solutions like Nix, though Lux’s author states one goal is precisely to make Lua-in-Nix ecosystems better.

Overall Reception

  • Many are enthusiastic that Lua finally gets a modern, dependency-aware manager, especially for Neovim and reproducible setups.
  • Skeptics question reliance on system detection, Rust/TOML aesthetics, and drift from Lua’s original “just embed it and unpack a zip” philosophy.