In reply to @esperlily:matrix.org
in fact, i’m pretty sure that if dynamic attributes did have recursive semantics then i could write an expression that is undecidable. i could write a pair of dynamic keys that would form a dependency loop, and i could write a dynamic key (or maybe a pair of them) that would cause a contradiction in evaluation, a key that evaluates to a given string if and only if it doesn’t evaluate to that string. dynamic attributes in a recset must be non-recursive. and that’s fine. i’d rather have non-recursive dynamic attributes then forbid having the dynamic attributes

In reply to @esperlily:matrix.org
and rec-set-dynamic-attrs in the manual still doesn’t actually make a good argument for why the behavior of that is considered bad. it makes perfect sense to me that a dynamic attr in a rec set is evaluated after the others (e.g. that the ability to reference keys from the recset in the dynamic attribute key demands that it be evaluated after) and also that the dynamic attribute itself doesn’t have recursive semantics, as the resulting key requires evaluating an expression and it doesn’t exist textually in the source. having the dynamic attribute have recursive semantics would be rather surprising. i am actually mildly surprised that rec { ${ “a” } = 1; b = a; } does in fact work, but in that case the attribute isn’t actually dynamic it just uses the same syntax (which is to say, the key does in fact exist textually in the source and can be statically known without actually evaluating anything) and so i don’t think it’s a problem that this works

Remote builders can be configured with TOML now

any chance on getting YAML/JSON configuration?