templated vars

[KiaraGrouwstra]

while vars currently support dependent variables, from the UX perspective this can still feel a bit clunky when one just wants to use such a parent variable within a file - or closer to us, within a nix configuration.

outside nix, templating has various existing languages - typically using interpolations like {{foo}} to substitute with foo's underlying value.

to construct configuration file using structured nix, there may be some further needs to take into account.
as one use-case, NixOS allows configuring nix itself using nix.settings, which has a sensitive attribute access-tokens.

this poses some challenges and considerations:

1. preventing sensitive data from hitting /nix/store - e.g. (as per the earlier example) from config.nix's pkgs.writeTextFile
2. retaining the UX of Nix and its language tooling like syntax highlighting and LSP - i.e. if possible still configure nix.settings rather than constructing the final file as string
3. avoiding awkward tricks with potential performance considerations like extendModules

a nice way to tackle this seems templated variables/secrets, as a vars-style backend-agnostic implementation of the nix-native solutions to this for sops and age, as i originally suggested in the upstream PR.

it would be cool if vars supported such a feature as well, even if not initially upstreamed.

[KiaraGrouwstra]

i tried a PoC for this for nix.settings.access-tokens, using a vars branch adding placeholders/templates.

(note that in this particular example, the UX is worse as nix.conf - rather than working with standard generators - uses a custom format.)

one area i feel less confident about is escaping, to make sure my cat interpolation could not break the sed expression.

for this implementation i further used placeholders modeled after sops-nix's, which uses characters </:/> that i do not yet feel confident play nice with all contexts we might want to use such placeholders in.
either way, i had not yet bothered with standard templating languages yet.

further, the user interface is kind of arbitrary here still, in this case generating placeholders the user may invoke from nix, while these could be left to the user as well - and in fact the user could instead just ignore these and use their own, altho here i did not currently make that vars.generators.*.files.*.placeholder configurable itself.

also, while $templates gets exposed to the user here in vars.generators.*.files.*.script under $templates/, as of yet performing replaces in the script is a burden placed on the user in this implementation still, whereas that could potentially be shifted to generate-vars as well. i picked path type for these figuring string content would be harder to get using lib.generators.

on generate-vars, its implementation here is currently tied to the default on-machine backend, meaning a burden would be placed on back-end implementers to add support for similar functionality there as well.

i don't so much feel confident enough to start a PR for this, but figured the important part might be to gather ideas now using one such concrete example - so hopefully these notes will inspire someone to see design choices wiser than those i made here. :)

[Lassulus]

https://pad.lassul.us/vars-templates#

[KiaraGrouwstra]

if you do manage an implementation separate from vars, we can close in favor of that one 😌🎉

[KiaraGrouwstra]

closing in favor of https://github.com/Lassulus/nix-templating