4 ms·

I'm excited to check it out, but why does this use a .toml file when Lua was already designed for configuration files? Why isn't it just a Lua script?

VWWHFSfQ 1y ago
I strongly prefer a declarative configuration instead of one that is fully-programmable. I want to be able to just look at a configuration and see what the settings are. Not have to account for the possibility that the config itself is also dependent on runtime variability.
- ecoffey 1y ago
  https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
- SOLAR_FIELDS 1y ago
  You just described in a concise way why I feel like “simple non DRY terraform configuration” is much better than “insane variable indirection to avoid like 20 lines of copy pasted code” Configs are configs. It’s better for them to be obvious and verbose than it is for them to be hard to understand and pithy. They don’t have the same requirements as the software that actually goes out on the release train.
  - thayne 1y ago
    The problem, which I've run into with terraform code like this, is when you need to change something in those 20 lines, and forget about one of the places you pasted, then spend hours trying to figure out why one system is behaving differently than the others (especially if the person debugging is different than the person who made the change).
    - SOLAR_FIELDS 1y ago
      Indeed, environment drift is definitely a problem with the aforementioned approach. There is some middle ground that enables code and variable reuse, but isn't some byzantine state machine that requires reciting magical incantations to work. Getting that middle balance is kind of tough. I think judicious use of tfvars and modules and workspace tagging can get you a long way without opening the pandoras box that is workspace orchestration.
- 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 ago
    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.
    - sitkack 1y ago
      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.
      - mrcjkb 1y ago
        We 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.
deleted 1y ago
[deleted]
juped 1y ago
It's cargo culting (pun intended).
soapdog 1y ago
from what I understand is because if it was a Lua script, it would be impossible for their interactive CLI to manipulate the list of dependencies. Imagine if the list of dependencies would be generated by a function with side-effects inside that Lua configuration script, it would be really hard to make any tool to fiddle with that.
- lvass 1y ago
  It works for Elixir, really well I may add.

VWWHFSfQ 1y ago

I strongly prefer a declarative configuration instead of one that is fully-programmable. I want to be able to just look at a configuration and see what the settings are. Not have to account for the possibility that the config itself is also dependent on runtime variability.

ecoffey 1y ago
https://en.m.wikipedia.org/wiki/Rule_of_least_power https://en.m.wikipedia.org/wiki/Rule_of_least_power
SOLAR_FIELDS 1y ago
You just described in a concise way why I feel like “simple non DRY terraform configuration” is much better than “insane variable indirection to avoid like 20 lines of copy pasted code” Configs are configs. It’s better for them to be obvious and verbose than it is for them to be hard to understand and pithy. They don’t have the same requirements as the software that actually goes out on the release train.
- thayne 1y ago
  The problem, which I've run into with terraform code like this, is when you need to change something in those 20 lines, and forget about one of the places you pasted, then spend hours trying to figure out why one system is behaving differently than the others (especially if the person debugging is different than the person who made the change).
  - SOLAR_FIELDS 1y ago
    Indeed, environment drift is definitely a problem with the aforementioned approach. There is some middle ground that enables code and variable reuse, but isn't some byzantine state machine that requires reciting magical incantations to work. Getting that middle balance is kind of tough. I think judicious use of tfvars and modules and workspace tagging can get you a long way without opening the pandoras box that is workspace orchestration.
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 ago
  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.
  - sitkack 1y ago
    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.
    - mrcjkb 1y ago
      We 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.

deleted 1y ago

[deleted]

juped 1y ago

It's cargo culting (pun intended).

soapdog 1y ago

from what I understand is because if it was a Lua script, it would be impossible for their interactive CLI to manipulate the list of dependencies. Imagine if the list of dependencies would be generated by a function with side-effects inside that Lua configuration script, it would be really hard to make any tool to fiddle with that.

lvass 1y ago
It works for Elixir, really well I may add.