Repository navigation
templated vars #1
Description
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:
- preventing sensitive data from hitting
/nix/store- e.g. (as per the earlier example) fromconfig.nix'spkgs.writeTextFile - retaining the UX of Nix and its language tooling like syntax highlighting and LSP - i.e. if possible still configure
nix.settingsrather than constructing the final file as string - 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.
Activity
KiaraGrouwstra commentedon May 3, 2025
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
catinterpolation could not break thesedexpression.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.*.placeholderconfigurable itself.also, while
$templatesgets exposed to the user here invars.generators.*.files.*.scriptunder$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 togenerate-varsas well. i picked path type for these figuring string content would be harder to get usinglib.generators.on
generate-vars, its implementation here is currently tied to the defaulton-machinebackend, 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 commentedon May 24, 2025
https://pad.lassul.us/vars-templates#
KiaraGrouwstra commentedon May 26, 2025
if you do manage an implementation separate from vars, we can close in favor of that one 😌🎉
KiaraGrouwstra commentedon May 28, 2025
closing in favor of https://github.com/Lassulus/nix-templating