8 ms·
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 d
by debugnik 1y ago
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.
- mrcjkb 1y agoWith 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.
- sitkack 1y agoThe 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.
- mrcjkb 1y agoWe want to be able to write updated dependency specs to the manifest.
- deleted 1y ago[deleted]
- VWWHFSfQ 1y ago> 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.