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.
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).
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.
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.
What if you're in the real world with tradeoffs? So you have both obvious downsides and obvious upsides mixed in each option, and what's more important, those depend on the user, not you, so you can't pick one best option?
That's the reason you give options, and you don't need to learn different ways, learn one you like better or just flip a coin
The zen of Python should be the zen of all languages.
>+ 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.)
Lua developers do, indeed, deserve a bit of lugubriousity with regards to describing luxurious things.
I’m all for ‘lux’ as a tool, if it can be used as the tip of the knife that delivers the pearly oyster.
For a lot of Lua projects, there are other extremes, by the way. There are helaciously discomfiting situations with regards Lua package management in certain environments.
If Lua gets something that makes it far, far easier to deploy, that pearl gets fatter.
Pip lets you create virtual environments. Does that mean it's an environment manager, not a package manager?
(╭ರ_•́)
