alt Hacker NewsI'm the author of nixtml. It's already doing IFD by using python to parse markdown content + metadata and superhtml to format the final HTML (a bit unnecessary, but I liked it while developing it).
I really wanted the templates to just be nix functions. It shouldn't be an issue to pass the context to an external program with `pkgs.runCommand` or something and then read the result (IFD like you mentioned).
Edit: I'm glad to hear you like it :)
Replies
lloeki • today at 6:07 PM
> I really wanted the templates to just be nix functions
This feels like Ruby template engines like haml† and slim†† a lot, or the various xml builders††† too
† https://github.com/haml/haml
†† https://slim-template.github.io
††† https://nokogiri.org/rdoc/Nokogiri/XML/Builder.html#class-No...
➕ show 1 reply
Yeah, it feels like the more conventional way would be doing the template-filling as a build step, so it's Nix just for the overall structure managing a fixed build graph, and then a per-page Python run to actually fill templates and generate the snippets/pages.
However, if you did want it to be nix all the way down and get more of that juicy dependency granularity, it could be more of a model where content and templates are transformed upfront into Nix source, which is then transformed and combined during evaluation. Obviously this is fairly slow in an IFD world where all that pre-work has to be serialized, but it would be interesting to experiment with what it looks like in a dynamic derivations context.