Crates.io | lux-cli |
lib.rs | lux-cli |
version | |
source | src |
created_at | 2025-02-18 21:40:45.243646+00 |
updated_at | 2025-04-23 21:21:17.761374+00 |
description | A luxurious package manager for Lua |
homepage | https://github.com/nvim-neorocks/lux |
repository | https://github.com/nvim-neorocks/lux |
max_upload_size | |
id | 1560496 |
Cargo.toml error: | TOML parse error at line 21, column 1 | 21 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
Key Features • How To Use • Comparison with Luarocks • Related Projects • Contributing
lux.toml
file.lx fmt
lx check
luacheck
.extra.rockspec
file, everything just works.luarocks
if it knows it has
to preserve maximum compatibility.[!WARNING]
Lux, while generally functional, is a work in progress and does not have a
1.0
release yet.
Feel free to consult the documentation on how to get started with Lux!
It features a tutorial and several guides to make you good at managing Lua projects.
luarocks
As this project is still a work in progress, some luarocks features have not been (fully) implemented yet. On the other hand, lux has some features that are not present in luarocks.
The following table provides a brief comparison:
lux | luarocks v3.11.1 | |
---|---|---|
project format | TOML / Lua | Lua |
add/remove dependencies | :white_check_mark: | :x: |
parallel builds/installs | :white_check_mark: | :x: |
proper lockfile support with integrity checks | :white_check_mark: | :x: (basic, dependency versions only) |
run tests with busted | :white_check_mark: | :white_check_mark: |
linting with luacheck | :white_check_mark: | :x: |
code formatting with stylua | :white_check_mark: | :x: |
automatic lua detection/installation | :white_check_mark: | :x: |
default build specs | :white_check_mark: | :white_check_mark: |
custom build backends | :white_check_mark:1 | :white_check_mark: |
rust-mlua build spec |
:white_check_mark: (builtin) | :white_check_mark: (external build backend) |
treesitter-parser build spec |
:white_check_mark: (builtin) | :white_check_mark: (external build backend) |
install pre-built binary rocks | :white_check_mark: | :white_check_mark: |
install multiple packages with a single command | :white_check_mark: | :x: |
install packages using version constraints | :white_check_mark: | :x: |
auto-detect external dependencies and Lua headers with pkg-config |
:white_check_mark: | :x: |
resolve multiple versions of the same dependency at runtime | :white_check_mark: | :white_check_mark: |
pack and upload pre-built binary rocks | :white_check_mark: | :white_check_mark: |
luarocks.org manifest namespaces | :white_check_mark: | :white_check_mark: |
luarocks.org dev packages | :white_check_mark: | :white_check_mark: |
versioning | SemVer2 | arbitrary |
rockspecs with CVS/Mercurial/SVN/SSCM sources | :x: (YAGNI3) | :white_check_mark: |
static type checking | :x: (planned) | :x: |
Dependencies:
openssl
libgit2
gnupg
, libgpg-error
and gpgme
(*nix only)lua
(optional, if building without the vendored-lua
feature)We recommend building with the vendored-lua
feature enabled:
cargo build --features vendored-lua
luarocks
under the hood, and will soon be undergoing a rewrite to use Lux instead.Credits go to the Luarocks team for maintaining luarocks and luarocks.org for as long as they have. Without their prior work Lux would not be possible.
Contributions are more than welcome! See CONTRIBUTING.md for a guide.
Supported via a compatibility layer that uses luarocks as a backend. ↩
Mostly compatible with the luarocks version parser, which allows an arbitrary number of version components. To comply with SemVer, we treat anything after the third version component (except for the specrev) as a prerelease/build version. ↩