mrcjkb (u/mrcjkb) - Readit News

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

MomsAVoxell · 2 months ago

Okay, sounds good, let’s see:

>+ Create and manage Lua projects

Yay!

>- Easily manage dependencies, build steps and more through the lux.toml file.

Boo! Ermm .. .toml?

You lost me at .toml.

Why is .toml being used to configure Lua?

(Disclaimer: I am a long term Lua user/developer and have a strong opinion about all things Lua.)

mrcjkb · 2 months ago

https://news.ycombinator.com/item?id=45626961#45630063

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

hgs3 · 2 months ago

> The ability to edit it using the CLI

This perplexes me. Lua was conceived as a configuration language and the whole point of a configuration language is you edit a config file. Trying to abstract this away behind a CLI seems like it misses the ethos of Lua.

It’s also a tad strange that a package manager designed for Lua isn’t written in Lua. Presumably Lua developers already have Lua installed, know Lua, and would more likely contribute to a project written in Lua.

mrcjkb · 2 months ago

> Lua was conceived as a configuration language

That alone is a pretty weak argument.

> Trying to abstract this away behind a CLI seems like it misses the ethos of Lua.

With `lx add <package>`, you can install the package and add it to und config file in one step. And do things like fail if the package or version doesn't exist or isn't compatible with your system.

You can provide editor plugins or use LSP to give users hints if there's an update available, and use code actions to update them, etc.

> It’s also a tad strange that a package manager designed for Lua isn’t written in Lua.

Again, the fact that Lux relates to Lua is a pretty weak argument for choosing Lua as a language to write or configure it in.

Lots of Lua libraries and packages aren't written in Lua, but are built with Lua bindings. Lua (which as you yourself just mentioned was conceived as a configuration language) is a pretty poor choice for something with the scope of Lux. In fact, luarocks was recently rewritten in Teal. Lux has a Lua API (lux-lua) which means it can be embedded or used as a Lua library.

> Presumably Lua developers already have Lua installed, know Lua, and would more likely contribute to a project written in Lua.

We're not worried about finding contributors. If anything, what we need are high quality contributions. Lua developers who only know Lua are not what we're looking for.

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

Crestwave · 2 months ago

It doesn't, no? You create virtual environments using Python's venv module, not pip. The newer alternatives like uv do handle it, though.

mrcjkb · 2 months ago

Right, my bad. Still, being able to do more to aid the creation and maintenance of packages than just install packages doesn't make something "not a package manager".

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

leptons · 2 months ago

"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.

mrcjkb · 2 months ago

It's just a silly pun. Search for "moon illuminance" and perhaps you'll get it :)

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

lucsky · 2 months ago

Because despite what the tagline says it's not a package manager, but a project manager.

mrcjkb · 2 months ago

Lux helps you install and create/maintain packages. Linting is a useful step in the creation of packages.

Pip lets you create virtual environments. Does that mean it's an environment manager, not a package manager?

(╭ರ_•́)

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

ModernMech · 2 months ago

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.

mrcjkb · 2 months ago

That's a neat idea, but it would mean we'd have to maintain our own library. When editing with the CLI, you have to make sure you preserve comments, which the toml-edit crate does quite well.

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

BugsJustFindMe · 2 months ago

> 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.

mrcjkb · 2 months ago

Good thing we're not giving options for no reason other than to give options ;)

mrcjkb commented on Lux: A luxurious package manager for Lua github.com/lumen-oss/lux... · Posted by u/Lyngbakr

ModernMech · 2 months ago

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.

mrcjkb · 2 months ago

> 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).