Hacker News Reader

Comment by debugnik | Hacker News Reader

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.

View on HN

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.

The function would be "compile time" so that function would be evaluated when you call `lx add <dependency@version>`, I'd also assume that the previous configuration would be cached and a diff shown of dependencies.

But I would also accept that it would be a subset of Lua that could define tables, but not contain functions. The data only declarative sublanguage.

We want to be able to write updated dependency specs to the manifest.

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

Reply on news.ycombinator.com