[HN Gopher] Lux: A luxurious package manager for Lua
___________________________________________________________________
Lux: A luxurious package manager for Lua
Author : Lyngbakr
Score : 59 points
Date : 2025-10-18 12:53 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ModernMech wrote:
| This is interesting but I feel like a lot of these Rust-inspired
| package managers are a little... _too_ inspired by Rust. This
| project for instance uses .toml as a config file format,
| presumably because that 's what Cargo does.
|
| But I think for this project in particular, Lua for the config
| files would have been a better choice!
|
| I think that Lua tries to be a good configuration language (it
| started as a configuration language called SOL (sun), which
| configured reports for lithology profiles), and in fact Luarocks
| uses "rockspec" for their config, which is syntactically Lua. Lux
| claims to be inspired by Luarocks, and yet they chose to use toml
| over lua for config. I'm wondering why? What was wrong with lua
| that made toml a better choice?
|
| edit: Okay, I've found more information where they say they
| support both formats... which, I don't know if that's the right
| call? Seems like going with one or the other is better from a
| project management standpoint, although I can see why they want
| to give users the option.
|
| > Not everyone may want to migrate (nor use) the TOML system for
| describing a project. For this reason, I'd had liked Lux to
| support a rockspec file alongside the TOML file (similar to the
| old project.rockspec format). This has finally been implemented!
| By creating a file called extra.rockspec in the project root, you
| will instruct Lux to merge the TOML and the rockspec together
| when performing any sort of operation.
| BugsJustFindMe wrote:
| > _I can see why they want to give users the option_
|
| I completely dislike the practice of giving options for no
| reason other than to give options. Don't make me learn
| different ways of doing the same thing to succeed in an
| ecosystem. Don't make me learn differences and similarities. If
| one way works properly and doesn't have obvious downsides,
| stick with having one way. If it has obvious downsides, stick
| with having a different one way. Subjective format taste isn't
| a real downside. Pick one format and stick with it.
|
| The line from the zen of Python about how "there should be
| one-- and preferably only one --obvious way to do it" is
| something that people all too often forget the value of.
| giancarlostoro wrote:
| > The line from the zen of Python about how "there should be
| one-- and preferably only one --obvious way to do it" is
| something that people all too often forget.
|
| The zen of Python should be the zen of all languages.
| BugsJustFindMe wrote:
| Yes, it should be. Sadly it's not even unambiguously the
| zen of Python these days.
| fullstop wrote:
| Yes, one way to do it. Sync or async!
| mrcjkb wrote:
| Good thing we're not giving options for no reason other than
| to give options ;)
| mrcjkb wrote:
| > presumably because that's what Cargo does.
|
| Nope. We chose TOML as the default for various reasons:
|
| - Simplicity. There are use cases for a turing complete
| configuration language. Lux is not one of them.
|
| - Ergonomics. The ability to edit it using the CLI
| (technically, that could be possible with Lua too, but it would
| be a lot more complex and not a very pleasant UX).
|
| > which, I don't know if that's the right call?
|
| The reason we currently support importing a Lua extra.rockspec
| is ease of migration for complex projects, e.g. with platform-
| specific overrides (not yet supported by the TOML spec).
| ModernMech wrote:
| Thanks that does answer my question! Had you considered
| parsing a subset of lua to get the properties you want? That
| way users don't have to learn a whole other syntax. I'm
| thinking in particular of my students whom I teach lua. They
| struggle enough learning one language, having to teach a
| second with all its quirks seems like a lot to throw at them.
| NuclearPM wrote:
| Do you think that is more difficult than explaining to the
| students why they can't use loops in their lua config
| files?
| ModernMech wrote:
| I wouldn't present it to them as "these config files are
| the same thing as Lua but without loops", but instead
| "these are config files and they have the same syntax as
| the Lua records we just learned about". And I would
| prefer that over "these are config files and they have a
| different syntax as the Lua records we just learned
| about." Although I can see merits on discussing that
| syntax differences exist between languages, that tends to
| overwhelm people learning their first language.
| leptons wrote:
| "beautiful", "elegant", and "tasteful" have all been used to puff
| up various libraries, frameworks, etc, and now we have
| "luxurious" to add to the long list of ridiculous adjectives used
| to puff up tech. Lovely.
| mmcromp wrote:
| Honestly it makes me roll my eyes, "let's describe our software
| utility as if we're trapped in a perfume commercial". But on
| the other hand, I think when creating something it does help to
| have underlying vision, even if it's abstract or doesn't quite
| make sense.
| dinkleberg wrote:
| I think that is why despite it being eye roll inducing, there
| is still value to these descriptors as it explains what they
| are going for. In this case it tells us they are prioritizing
| the feel over everything else and for a package manager that
| is pretty solid focus.
| otikik wrote:
| I have always thought that those qualities should be shown, not
| said. Both in software and in life.
| NuclearPM wrote:
| I don't understand why a package manager needs lint support.
| lucsky wrote:
| Because despite what the tagline says it's not a package
| manager, but a project manager.
| acephal wrote:
| I've been awaiting the rocks.nvim team to migrate to this
___________________________________________________________________
(page generated 2025-10-18 23:00 UTC)