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