Show HN: Lux – A luxurious package manager for Lua

[nerflad]

Execution env is the achille's heel of scripting languages. Personally I don't use Neovim, but had a feeling its adoption would spur development in this area for Lua. Bryan Cantrill called Javascript "LISP in C's clothes". In some ways I feel like Lua is the opposite, and love it for those reasons (disclaimer: never had to use it at work).

[jmercouris]

Javascript is Lisp in C's clothes? On what basis? Also what does Lua have to do with Lisp? It has no Lisp syntax whatsoever.

[jjtech]

I know some projects like Koreader[1] use Lua as their primary application language. If you could convince one of them to switch, it would provide some assurances about the maturity and popularity of the idea.

[1]: https://github.com/koreader/koreader

[mrcjkb]

That's a neat suggestion, thanks. Lux will need some time to become mature, but building a large multi-platform project like koreader would definitely be a nice goal.

[MyOutfitIsVague]

This sounds amazing. I use Lua a lot, and luarocks has been nearly useless for anything I need it to do because it's so heavily opinionated. For anything more than "install a library specifically for direct execution on the local system" or anything around that, it's a non starter. Have an embedded scripting environment that works with Lua packages and you want to package scripts with dependencies for use there? Give up.

I don't know if this is better for that use case, but even if not, luarocks is clunky and annoying to use at best.

[shortrounddev2]

the lua community is also incredibly dependent on C libraries, and nearly every luarocks package tries to build libs, which makes it basically useless on Windows

[droelf]

Interesting project. We'd love to work together for better Lua support in Pixi (through the conda-forge ecosystem). We already package lua and a few C extensions. C extensions are the bread and butter for Pixi, so I think it could be a good fit!

- pixi.sh (docs) - lua package on the registry: https://prefix.dev/channels/conda-forge/packages/lua

[andrewmcwatters]

I don't see this listed here or the other associated sites, so I'll ask:

1. Does this integrate natively with `package.path` and `package.cpath`?

2. Does it detect non-standard, popular installations like through brew(1)?

3. Can you install by GitHub `:user/:repository`?

Also, neat project! Nice work.

[mrcjkb]

1. The commands, `lx run` and `lx lua` will set the `PATH`, `LUA_PATH` and `LUA_CPATH`. And there's a `lx path` command for setting those environment variables.

2. It defaults to using pkg-config to detect Lua installations and will fall back to installing Lua via the `lua_src` and `luajit_src` crates if it can't find them. We may eventually add support for other tools like vcpkg.

3. Not yet. It's on our roadmap to add support for that to our lux.toml/dependencies spec, but we probably won't allow rockspecs with that to be published to luarocks.org, because we don't want to be the reason people publish packages that can't be built by luarocks.

Thanks :)

[inftech]

A package manager written in Rust for a language designed to be embedded in C and which relies heavily on C libraries, and also configured in TOML when Lua itself was created to be used as a configuration language in C programs?

No, thanks.

Luarocks has its limits and probably should be rewritten, but using a language that fits the ecosystem and following the culture of the Lua ecosystem.

Rust and Cargo represent exactly the opposite of Lua.

[zokier]

Personally I'm really tired of all these language specific package managers. I just don't feel that is the right direction, stuff like nix seem like much better approach.

[mrcjkb]

One of the motivations for Lux is to improve the nixpkgs Lua and Neovim ecosystems.

[1vuio0pswjnm7]

A package manager for Lua that depends on Rust.

[legends2k]

I see no problem though. Most package managers support binary-only package installations.

[mrcjkb]

You might be surprised how well that works :)

[kreco]

And TOML.

[rcarmo]

I like this. I've been wanting to have a reproducible way to install Lua packages across machines for a while now.

[MomsAVoxell]

I have achieved this state of affairs, reproducible Lua package installs across machines, but I mostly use Lua either in a) “raw” form (linking to the VM internally) in which case I simply manage a .lua codebase as part of the project build, or b) as a system tool, wherein judicious use of “luarocks —local” and such tools as luaenv, have given me everything I need to stick in a Makefile/CMakeLists.txt file .. and to package into a bundle for distribution, a sprinkling of luastatic.

To be honest, none of this is any different for python, or any of the other scripted languages which might be found ‘onboard’; however, one must always differentiate between the system-provided /bin/script_language, and one which might be being used as a development tool/scripting engine in a larger project, or indeed .. local tooling .. workbench.

One of the reasons I like Lua so darn much, is that its really easy and fun to get all the libs packaged up, bytecode linked, bundle wrapped up, and have a single-click install for your intended users’ operating system, quite effectively.

But yeah, you do sort of have to flex some limbs.

[binary132]

This is great and everything but it really feels to me like this is going in the opposite direction of the design of Lua as a simple embedding language, where “package management” means downloading and unpacking a couple of zips, and “version management” means choosing whether to write for 5.1 compatibility, or 5.4 compatibility.

[Arch485]

Why not use Lua for config instead of TOML? IIRC Lua was originally a data schema language, so it should be good for it.

[tengbretson]

Is there a good reason to introduce the halting problem to a package manifest?

[mrcjkb]

With Lua, it becomes near impossible for a program like lux to edit the manifest.

For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?

[debugnik]

I'm excited to check it out, but why does this use a .toml file when Lua was already designed for configuration files? Why isn't it just a Lua script?

[VWWHFSfQ]

I strongly prefer a declarative configuration instead of one that is fully-programmable. I want to be able to just look at a configuration and see what the settings are. Not have to account for the possibility that the config itself is also dependent on runtime variability.

[juped]

It's cargo culting (pun intended).

[soapdog]

from what I understand is because if it was a Lua script, it would be impossible for their interactive CLI to manipulate the list of dependencies. Imagine if the list of dependencies would be generated by a function with side-effects inside that Lua configuration script, it would be really hard to make any tool to fiddle with that.

[ivanjermakov]

Thank you for treating neovim ecosystem first-class. During plugin development I missed ease of use of third party libraries I have with e.g. Rust and Typescript.

[johnisgood]

Has anyone used this? In my ~/.bash_profile, I have "eval "$(luarocks path --bin)"" which is very slow, and it needs to be called. How does this work with "lux"?

Additionally, I think there should be examples on the website of typical workflow(s).

Additionally, is "luvit" integrated in some way or another?

Additionally, does it work with LuaJIT? I assume it does, but worth a question.

[mrcjkb]

- There's an equivalent `lx path bin` command, but there's also a `lx run` that lets you run installed packages.

- We're still quite early on in development, so documentation and things like error messages will need fleshing out.

- We don't have luvit integration yet

- Yes, it also works with LuaJIT, either via pkg-config or by installing LuaJIT headers using the `luajit_src` crate.

[zaruvi]

This looks interesting. At one point I wanted to use a third party library using luarocks, but I gave up because it wasn't immediately working/straight-forward. It may have been a skill issue though...

[andrewmcwatters]

In my experience, most people don't use luarocks anyway.

[thundervelvet]

Nice! Lua really needed something like this to make packages easier.

[Onavo]

How do you deal with the diamond dependency problem? Do you allow two different versions of a package to be exist simultaneously?

[mrcjkb]

Yes, we have a `lux-lua` library (which we will need to bundle with `lux-cli`) that exposes a `lux.loader` module. It uses the lockfile to resolve dependencies.

[meel-hd]

The website doesn't look that much luxuries, I would love to help with that.

[redleader55]

Luxurious? What a pointless epithet for a package manager

[opem]

finally, someone did it! luarocks was never an intuitive solution, and I feel this unintuitive ecosystem is one of the reasons for lua's low adoption.

[VWWHFSfQ]

> one of the reasons for lua's low adoption

I think moreso is the complete lack of any "batteries included" whatsoever. Not even something so basic as sockets are supported by Lua's stdlib. The ecosystem has had to fill so many gaps and a lot of that is dependent on Leafo and LuaRocks.

I'm hoping the great mlua Rust crate will help build the ecosystem since now it's mostly trivial to build easily-distributable native Lua packages in Rust.