16 ms·

Show HN: Lux – A luxurious package manager for Lua

268 points by mrcjkb 2y ago

andrewmcwatters 2y ago
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 2y ago
  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 2y ago
    > 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 ..
    - mrcjkb 2y ago
      The usefulness of a local Lua bundle depends on whether you're packaging a library or an application. pkg-config can search by version, so you're not going to end up trying to build a Lua 5.4 package with Lua 5.2 with Lux. If you need a reproducible Lua installation, you can configure pkg-config - That works quite well in nixpkgs, for example. Or, you can just disable pkg-config and let Lux install the correct Lua version for you. We don't provide a way to dump a Lua bundle, but in principle that would be easy to add if users request it.
    - shakna 2y ago
      Coming from the other direction, luarocks binding to just one version of Lua, is an absolute pain in the ass. I've got some libraries that support five or six different versions of Lua. Building packages for all of them basically means throwing luarocks out the window, because linking to multiple Lua runtimes ti=o luarocks does all kinds of truly heinous things. You can end up with the library and headers linked from different runtimes, simply because it isn't following what the local system says is available.
johnea 2y ago
[flagged]
- deleted 2y ago
  [deleted]
zaruvi 2y ago
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 2y ago
  In my experience, most people don't use luarocks anyway.
  - MomsAVoxell 2y ago
    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™ in my opinion.
    - shortrounddev2 2y ago
      luarocks has too many packages which require building C libs from scratch. It's basically unusable on Windows
      - mjmas 2y ago
        as long as I'm in a vs developer prompt on mine I haven't had a problem. I did build my own Lua though.
      - johnisgood 2y ago
        And to make things worse, many of them do not compile successfully. That said, luarocks is still easy to use, the problem is unmaintained packages.
  - johnisgood 2y ago
    They should, it is a breeze.
rcarmo 2y ago
I like this. I've been wanting to have a reproducible way to install Lua packages across machines for a while now.
- MomsAVoxell 2y ago
  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 2y ago
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 2y ago
  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 2y ago
    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/ https://fennel-lang.org/
    - creata 2y ago
      And Tcl has strings. Fennel is more popular than I expected! It's in the official repositories of Arch, Fedora and Debian.
    - cmdrk 2y ago
      as a Lisp-curious person, Fennel was a gateway drug for me
      - 0x3444ac53 2y ago
        Fennel is phenomenal, and is the reason I switched from chicken scheme to clojure/babashka despite hating the JVM. Neovim config, Wezterm Config, and various scripts to do things are all now written in fennel. I've also used it for game dev using Love2D. It's a great great language, and fixes a LOT of the issues I have with Lua.
deleted 2y ago
[deleted]
opem 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
      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.
- deleted 2y ago
  [deleted]
jjtech 2y ago
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 https://github.com/koreader/koreader
- mrcjkb 2y ago
  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 2y ago
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 2y ago
  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 2y ago
    https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
  - SOLAR_FIELDS 2y ago
    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 2y ago
      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 2y ago
        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.
Arch485 2y ago
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 2y ago
  Is there a good reason to introduce the halting problem to a package manifest?
  - hgs3 2y ago
    Lua has a sandboxed runtime so couldn't you kill rogue scripts after a timeout?
    - giraffe_lady 2y ago
      Would you rather do that or use toml?
      - hgs3 2y ago
        Lua was designed for configuration, so I'd rather use Lua. Plus, it makes for a more elegant, unified design. TOML, and friends, are better paired with languages that were not designed for configuration.
        giraffe_lady 2y ago
        I know what lua was designed for and have professional experience with it. It's not that great as a config language imo, I can easily understand why a project would use something else.
        pmarreck 2y ago
        It seems like every new language community and generation of developers needs to re-learn a set of the same lessons (why declarative instead of imperative config is the way to go, why functional is superior to imperative, why immutable is superior to mutable, why TDD (or just unit testing) is important, why hexagonal design is the best organization of logic, why static typing is important, why Nix is the only valid global package manager, etc. etc. etc.) and I suspect it's because these problems all share the same attributes: 1) the inferior solution seems easier at first (but won't be in the long run) 2) the people blithely picking the inferior solution have not yet encountered enough of the thorny nastiness that the initially-harder option completely prevents the end result being that all the "greybeards" have settled on the "initially harder" solutions for things because they all learned the hard way that it just causes less headaches in the long run
firtoz 2y ago
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 2y ago
  > 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/ https://tinysse.com/ [1] https://github.com/mlua-rs/mlua https://github.com/mlua-rs/mlua
johnisgood 2y ago
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 2y ago
  - 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 2y ago
    > - 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.
    - mrcjkb 2y ago
      Only the `lx --help` and man pages.
      - johnisgood 2y ago
        I will take a look when I get into Lua again. :)
pmarreck 2y ago
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 2y ago
  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 2y ago
    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.
    - frfl 2y ago
      Dependency problems are mainly resolved with uv - try it. 1 way to do things - not sure what you mean. It's a general purpose language, if you dont like something there's probably a different library that may do it the way you like (eg, don't like exceptions, use a library that mimics rust style Result values; don't like oop, don't do oop, functional programming is certainly possible in python), or easy enough to start creating your own private utility libraries that do things your way. Xonsh was okay. Idk if I'd use it again. I'd probably just use python to invoke external cli programs using subprocess. I used xonsh for scripting before. I recall it having a slightly slow start up - I launch shell frequently so that's a no-go for me to use as my default shell. --- And I looked at alternative scripting languages. Racket, D (has a single file script mode), ocaml, etc. Honestly python seemed good enough, even with its warts, especially with uv to manage deps without a whole formal project needing to be setup for a script. Stwp up from bash. Most of my use cases are fine with argparse + subprocesses + a unix shebang at the top + "chmod +x", with uv handy if I need a external library.
Onavo 2y ago
How do you deal with the diamond dependency problem? Do you allow two different versions of a package to be exist simultaneously?
- mrcjkb 2y ago
  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.
MyOutfitIsVague 2y ago
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 2y ago
  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
  - giraffe_lady 2y ago
    Useless if you need to run it in a scripting environment where you don't have control over runtime too. The thing lua was designed and is still prominently used for.
ivanjermakov 2y ago
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.
1vuio0pswjnm7 2y ago
A package manager for Lua that depends on Rust.
- kreco 2y ago
  And TOML.
- mrcjkb 2y ago
  You might be surprised how well that works :)
- legends2k 2y ago
  I see no problem though. Most package managers support binary-only package installations.
redleader55 2y ago
Luxurious? What a pointless epithet for a package manager
droelf 2y ago
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 https://prefix.dev/channels/conda-forge/packages/lua
- mrcjkb 2y ago
  That sounds like a great idea! I've opened [an issue](https://github.com/nvim-neorocks/lux/issues/550 https://github.com/nvim-neorocks/lux/issues/550) in our repo. Feel free to ping us there :)
zokier 2y ago
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 2y ago
  One of the motivations for Lux is to improve the nixpkgs Lua and Neovim ecosystems.
kunley 2y ago
Standard to unify previous standards, huh? https://xkcd.com/927/ https://xkcd.com/927/ ;) (PS. I really cheer on Lua community having a decent package manager. Couldn't resist, though)
thundervelvet 2y ago
Nice! Lua really needed something like this to make packages easier.
- naksnsnd 2y ago
  [flagged]
inftech 2y ago
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.
- mrcjkb 2y ago
  Lua has evolved and is used for a lot more today than it was initially created for.
meel-hd 2y ago
The website doesn't look that much luxuries, I would love to help with that.
- mrcjkb 2y ago
  You mean my Hakyll site? It's mot meant to be :)
binary132 1y ago
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.

268 points by mrcjkb 2y ago

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 2y ago
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 2y ago
  > 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 ..
  - mrcjkb 2y ago
    The usefulness of a local Lua bundle depends on whether you're packaging a library or an application. pkg-config can search by version, so you're not going to end up trying to build a Lua 5.4 package with Lua 5.2 with Lux. If you need a reproducible Lua installation, you can configure pkg-config - That works quite well in nixpkgs, for example. Or, you can just disable pkg-config and let Lux install the correct Lua version for you. We don't provide a way to dump a Lua bundle, but in principle that would be easy to add if users request it.
  - shakna 2y ago
    Coming from the other direction, luarocks binding to just one version of Lua, is an absolute pain in the ass. I've got some libraries that support five or six different versions of Lua. Building packages for all of them basically means throwing luarocks out the window, because linking to multiple Lua runtimes ti=o luarocks does all kinds of truly heinous things. You can end up with the library and headers linked from different runtimes, simply because it isn't following what the local system says is available.

johnea 2y ago

[flagged]

deleted 2y ago
[deleted]

zaruvi 2y ago

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 2y ago
In my experience, most people don't use luarocks anyway.
- MomsAVoxell 2y ago
  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™ in my opinion.
  - shortrounddev2 2y ago
    luarocks has too many packages which require building C libs from scratch. It's basically unusable on Windows
    - mjmas 2y ago
      as long as I'm in a vs developer prompt on mine I haven't had a problem. I did build my own Lua though.
    - johnisgood 2y ago
      And to make things worse, many of them do not compile successfully. That said, luarocks is still easy to use, the problem is unmaintained packages.
- johnisgood 2y ago
  They should, it is a breeze.

rcarmo 2y ago

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

MomsAVoxell 2y ago
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 2y ago

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 2y ago
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 2y ago
  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/ https://fennel-lang.org/
  - creata 2y ago
    And Tcl has strings. Fennel is more popular than I expected! It's in the official repositories of Arch, Fedora and Debian.
  - cmdrk 2y ago
    as a Lisp-curious person, Fennel was a gateway drug for me
    - 0x3444ac53 2y ago
      Fennel is phenomenal, and is the reason I switched from chicken scheme to clojure/babashka despite hating the JVM. Neovim config, Wezterm Config, and various scripts to do things are all now written in fennel. I've also used it for game dev using Love2D. It's a great great language, and fixes a LOT of the issues I have with Lua.

deleted 2y ago

[deleted]

opem 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
    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.
deleted 2y ago
[deleted]

jjtech 2y ago

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 https://github.com/koreader/koreader

mrcjkb 2y ago
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 2y ago

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 2y ago
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 2y ago
  https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
- SOLAR_FIELDS 2y ago
  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 2y ago
    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 2y ago
      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.

Arch485 2y ago

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 2y ago
Is there a good reason to introduce the halting problem to a package manifest?
- hgs3 2y ago
  Lua has a sandboxed runtime so couldn't you kill rogue scripts after a timeout?
  - giraffe_lady 2y ago
    Would you rather do that or use toml?
    - hgs3 2y ago
      Lua was designed for configuration, so I'd rather use Lua. Plus, it makes for a more elegant, unified design. TOML, and friends, are better paired with languages that were not designed for configuration.
      - giraffe_lady 2y ago
        I know what lua was designed for and have professional experience with it. It's not that great as a config language imo, I can easily understand why a project would use something else.
      - pmarreck 2y ago
        It seems like every new language community and generation of developers needs to re-learn a set of the same lessons (why declarative instead of imperative config is the way to go, why functional is superior to imperative, why immutable is superior to mutable, why TDD (or just unit testing) is important, why hexagonal design is the best organization of logic, why static typing is important, why Nix is the only valid global package manager, etc. etc. etc.) and I suspect it's because these problems all share the same attributes: 1) the inferior solution seems easier at first (but won't be in the long run) 2) the people blithely picking the inferior solution have not yet encountered enough of the thorny nastiness that the initially-harder option completely prevents the end result being that all the "greybeards" have settled on the "initially harder" solutions for things because they all learned the hard way that it just causes less headaches in the long run

firtoz 2y ago

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 2y ago
> 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/ https://tinysse.com/ [1] https://github.com/mlua-rs/mlua https://github.com/mlua-rs/mlua

johnisgood 2y ago

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 2y ago
- 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 2y ago
  > - 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.
  - mrcjkb 2y ago
    Only the `lx --help` and man pages.
    - johnisgood 2y ago
      I will take a look when I get into Lua again. :)

pmarreck 2y ago

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 2y ago
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 2y ago
  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.
  - frfl 2y ago
    Dependency problems are mainly resolved with uv - try it. 1 way to do things - not sure what you mean. It's a general purpose language, if you dont like something there's probably a different library that may do it the way you like (eg, don't like exceptions, use a library that mimics rust style Result values; don't like oop, don't do oop, functional programming is certainly possible in python), or easy enough to start creating your own private utility libraries that do things your way. Xonsh was okay. Idk if I'd use it again. I'd probably just use python to invoke external cli programs using subprocess. I used xonsh for scripting before. I recall it having a slightly slow start up - I launch shell frequently so that's a no-go for me to use as my default shell. --- And I looked at alternative scripting languages. Racket, D (has a single file script mode), ocaml, etc. Honestly python seemed good enough, even with its warts, especially with uv to manage deps without a whole formal project needing to be setup for a script. Stwp up from bash. Most of my use cases are fine with argparse + subprocesses + a unix shebang at the top + "chmod +x", with uv handy if I need a external library.

Onavo 2y ago

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

mrcjkb 2y ago
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.

MyOutfitIsVague 2y ago

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 2y ago
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
- giraffe_lady 2y ago
  Useless if you need to run it in a scripting environment where you don't have control over runtime too. The thing lua was designed and is still prominently used for.

ivanjermakov 2y ago

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.

1vuio0pswjnm7 2y ago

A package manager for Lua that depends on Rust.

kreco 2y ago
And TOML.
mrcjkb 2y ago
You might be surprised how well that works :)
legends2k 2y ago
I see no problem though. Most package managers support binary-only package installations.

redleader55 2y ago

Luxurious? What a pointless epithet for a package manager

droelf 2y ago

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 https://prefix.dev/channels/conda-forge/packages/lua

mrcjkb 2y ago
That sounds like a great idea! I've opened [an issue](https://github.com/nvim-neorocks/lux/issues/550 https://github.com/nvim-neorocks/lux/issues/550) in our repo. Feel free to ping us there :)

zokier 2y ago

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 2y ago
One of the motivations for Lux is to improve the nixpkgs Lua and Neovim ecosystems.

kunley 2y ago

Standard to unify previous standards, huh? https://xkcd.com/927/ https://xkcd.com/927/ ;) (PS. I really cheer on Lua community having a decent package manager. Couldn't resist, though)

thundervelvet 2y ago

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

naksnsnd 2y ago
[flagged]

inftech 2y ago

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.

mrcjkb 2y ago
Lua has evolved and is used for a lot more today than it was initially created for.

meel-hd 2y ago

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

mrcjkb 2y ago
You mean my Hakyll site? It's mot meant to be :)

binary132 1y ago

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.