[HN Gopher] Show HN: Lux - A luxurious package manager for Lua
___________________________________________________________________
Show HN: Lux - A luxurious package manager for Lua
Author : mrcjkb
Score : 138 points
Date : 2025-04-07 18:13 UTC (4 hours ago)
(HTM) web link (mrcjkb.dev)
(TXT) w3m dump (mrcjkb.dev)
| andrewmcwatters wrote:
| 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 wrote:
| 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 :)
| MomsAVoxell wrote:
| > pkg-config to detect Lua installations
|
| I have a strong opinion on this, as a Lua developer with some
| experience shipping Lua code.
|
| Good third-party package management for Lua should function
| independently from the system-provided Lua installations.
|
| It's all too easy for newcomers to the Lua app-development
| world to tie themselves into some "auto-detected Lua" path
| that is, frankly, bonkers. It makes things hard to ship.
|
| If you're going to write a Lua app, and want to manage your
| Lua dependencies - use 'luarocks --local' and leave system-
| provided resources out of the picture.
|
| Bundle Lua up front.
|
| This is true of python, also: if you're going to try to build
| an app that uses either Lua/python, one must take
| responsibility for building and bundling locally, and not
| using system-provided lua/python bindings.
|
| Sure, use "brew ---prefix lua" to get things started, if that
| has to be a thing. Use pkg-config too, to build the
| "System/Package-Manager provided" lists.
|
| One of the best practices for luarocks is to know and use the
| ---local flag with gusto and bravado, and include its
| artifacts in a larger app build/bundling target. This can be
| done in a cross-platform manner for all of the major
| platforms. Having a build target with a successful 'luarocks
| --local', for a locally built Lua and dependencies, does
| indeed rock. You can put everything in a .local/lua ... and
| treat it just like any other linkable object resource.
|
| If there is one solid rule for effective Lua development, it
| is: leave the system Lua's alone, and build your own
| .local/lua tree, properly.
|
| If you can't do that, you'll be missing out on the grand
| prize: being able to ship Lua with certainty that your Lua
| bundle will work, regardless of whats onboard the users'
| setup ... which is, after all, kind of a holy grail of the
| language, and therefore also a priority of its package
| management tools.
|
| Another "Lua dev maxim" is, there are many Lua's. There are
| reasons to use Lua 5.1 in a project - and reasons to use 5.4
| and LuaJIT, too. Switching Lua's is why I luaenv, but also,
| you can bootstrap a fresh Lua with CMake real fast, either as
| a project tool/binary, or directly to the VM abstractions,
| integrated into your app. A great Lua project has Lua 5.4 in
| the project, and both developer and end-user host binaries
| which include a Lua 5.4 environment, sandboxed, built from
| exactly the same sources. Bonus points for the Desktop/Mobile
| bridge getting crossed ..
|
| So, depending on a system Lua, is repeating the same mistake
| prior lua package managers made, maybe. I have reached
| nirvana with luaenv+luarocks+cmake, personally.
|
| I'm not suggesting lux not try to be self-aware on the basis
| of finding system standard tooling and libraries for its
| purposes, but that to be better than luarocks, lux will have
| to be able to handle ---local builds just as well ..
|
| Luarocks is not just about being a 'pip for Lua', its also
| about having everything relatively tidy to support a fully
| local build and packaging target. With luarocks you can not
| use the system Lua, entirely - and that is a pretty
| significant use-case for luarocks, its utility in the
| packaging steps ..
| zaruvi wrote:
| 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 wrote:
| In my experience, most people don't use luarocks anyway.
| MomsAVoxell wrote:
| luarocks is easy to use, once you understand the importance
| of ---local all-the-things.
|
| Anyway, luarocks is easy to use, and is perfectly easy to
| integrate into most modern build and distribution tools.
|
| However, Lua is _everywhere_ , so of course: ymmv.
| Disclaimer: I've been using Lua for decades now, its Just
| Great(tm) in my opinion.
| johnisgood wrote:
| They should, it is a breeze.
| rcarmo wrote:
| I like this. I've been wanting to have a reproducible way to
| install Lua packages across machines for a while now.
| MomsAVoxell wrote:
| 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.
| nerflad wrote:
| 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 wrote:
| 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.
| 0x3444ac53 wrote:
| Fennel has actually convinced me that Lua and lisp have more
| in common than one might think. I don't know what the above
| comment was referencing, but I've always found beauty in lisp
| languages for having a primary datastructure that all others
| can be abstracted to. Lisp, classically, has list, clojure
| has sequences, and Lua/fennel has tables.
|
| https://fennel-lang.org/
| creata wrote:
| And Tcl has strings.
|
| Fennel is more popular than I expected! It's in the
| official repositories of Arch, Fedora and Debian.
| 0x3444ac53 wrote:
| Also, I do want to point out that despite very recognizable
| syntax, that's not the only thing that makes lisp lisp.
| Primary example of lisp-y syntax on a non-lisp would be Janet
| [0]
|
| https://janet-lang.org/
| opem wrote:
| 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 wrote:
| > 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.
| acureau wrote:
| Lua fills its niche of no-fluff embeddable scripting language
| perfectly, the idea is to bind to your own code. It makes
| sense to me that they wouldn't focus heavily on the standard
| library. I think that if there is a large enough community of
| people who want to use Lua as a general purpose scripting
| language, they should maintain an unofficial stdlib.
| VWWHFSfQ wrote:
| Oh certainly and I'm not arguing against Lua's decisions to
| have a small stdlib. Just commenting on why it has seen low
| adoption outside of specific niches like scripting game
| engines, etc.
| jjtech wrote:
| 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 wrote:
| 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.
| debugnik wrote:
| 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 wrote:
| 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.
| ecoffey wrote:
| https://en.m.wikipedia.org/wiki/Rule_of_least_power
| SOLAR_FIELDS wrote:
| You just described in a concise way why I feel like "simple
| non DRY terraform configuration" is much better than "insane
| variable indirection to avoid like 20 lines of copy pasted
| code"
|
| Configs are configs. It's better for them to be obvious and
| verbose than it is for them to be hard to understand and
| pithy. They don't have the same requirements as the software
| that actually goes out on the release train.
| thayne wrote:
| The problem, which I've run into with terraform code like
| this, is when you need to change something in those 20
| lines, and forget about one of the places you pasted, then
| spend hours trying to figure out why one system is behaving
| differently than the others (especially if the person
| debugging is different than the person who made the
| change).
| SOLAR_FIELDS wrote:
| Indeed, environment drift is definitely a problem with
| the aforementioned approach. There is some middle ground
| that enables code and variable reuse, but isn't some
| byzantine state machine that requires reciting magical
| incantations to work. Getting that middle balance is kind
| of tough. I think judicious use of tfvars and modules and
| workspace tagging can get you a long way without opening
| the pandoras box that is workspace orchestration.
| debugnik wrote:
| What variability? Lua can be easily sandboxed to not take any
| inputs: Running it would express the same manifest. And most
| Lua configurations would still read declaratively unless they
| needed extra the complexity.
|
| I just think it's a shame that the manifest file for Lua
| projects would be in a language other than Lua itself. I'm
| more sympathetic to other trade-offs, though, such as being
| able to edit the file mechanically.
| mrcjkb wrote:
| 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?
|
| Lux defaults to TOML, but if you really want Lua, it also
| supports an `extra.rockspec` in the project root, which
| shares the same format as the luarocks RockSpec format.
| VWWHFSfQ wrote:
| > most Lua configurations would still read declaratively
| unless they needed extra the complexity
|
| This is precisely the problem. If you allow runtime
| configuribility then people will do it. I don't want my
| engineers to even have the option to meta-program the
| configuration file.
| Arch485 wrote:
| 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 wrote:
| Is there a good reason to introduce the halting problem to a
| package manifest?
| mrcjkb wrote:
| 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?
| mikepurvis wrote:
| Indeed. I'm glad for us to have learned Python's 20 year
| lesson on the dangers of an executable manifest.
| firtoz wrote:
| Perfect timing, I just added Lua integration to our product ( my
| bio has details ) for an AI agent to run code on.
|
| Cannot wait to see Lua come back in full force. I had used it
| ages ago to build World of Warcraft plugins, then came back with
| Roblox, then back again for AI.
| benwilber0 wrote:
| > Cannot wait to see Lua come back in full force.
|
| I also recently released a server for Server-Sent Events [0]
| that is programmable with Lua. Overall it's been a great
| experience. The Rust mlua-rs crate [1] is trivially easy to
| integrate.
|
| [0] https://tinysse.com/
|
| [1] https://github.com/mlua-rs/mlua
| johnisgood wrote:
| 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 wrote:
| - 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.
| johnisgood wrote:
| > - Yes, it also works with LuaJIT, either via pkg-config or
| by installing LuaJIT headers using the `luajit_src` crate.
|
| Are there any documentation on this?
|
| luarocks works with luajit after I run that specific command,
| I expect something like that as it is very easy, so I wonder
| if running "lx path bin" would work.
| pmarreck wrote:
| I've been shopping around for a scripting language to replace
| Bash for commandline stuff, which also doesn't have a significant
| startup time, is Lua something I should look at?
| frfl wrote:
| Idk about lua, but uv single file python scripts (search the
| phrase) may be highly relevant for you. Or pure python, if you
| don't need to pull in any dependencies.
| pmarreck wrote:
| I try to keep very few programming rules, but one which has
| emerged over time is "no python unless absolutely necessary"
| (precisely because of the thing you hinted at- the dependency
| problem, which I've run into one time too many, but also, the
| whole concept of there being only 1 way to do things _which
| is kind of enforced_ just always rubbed me the wrong way)
|
| But yes, in theory, that might be nice! There's also the
| Python-powered shell, Xonsh, which I can't use either.
| Onavo wrote:
| How do you deal with the diamond dependency problem? Do you allow
| two different versions of a package to be exist simultaneously?
| mrcjkb wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-07 23:00 UTC)