Potentially/Eventually these formats might be implemented using lazyAttrsOf (or what becomes of it) from #70138, such that self-dependent assignments of them will be possible. Edit: This is now done in this PR :)

@infinisil awesome stuff!

(This still needs a bit of docs probably and a history cleanup at least btw, before anybody merges)

I've now rebased this ontop of #70138 to implement types where values can depend on other values. E.g. this previously threw an infinite recursion error, but now it doesn't anymore:

{ lib, config, ... }:
let format = lib.formats.json;
in {
  options.settings = lib.mkOption {
    type = format.type;
    default = {};
  };

  config = {
    settings.foo = true;
    settings.bar = lib.mkIf config.settings.foo "Foo is true!";

    environment.etc.test.text = format.generate config.settings;
  };
}

Due to how the implementation works, it's however a bit more cumbersome if you aren't sure whether an attribute exists at all. This is how that can now be handled gracefully:

{
  # To make sure the `.name` attribute exists
  settings.name = format.empty;
  # To handle the case of `.name` being empty
  settings.greeting = "Hello, ${format.get "nobody" config.settings.name}!";
}

This will generate { greeting = "Hello, nobody!"; }

Alternatively if you don't mind name being set:

{
  settings.name = lib.mkDefault "nobody";
  settings.greeting = "Hello, ${config.settings.name}!";
}

Which will generate { name = "nobody"; greeting = "Hello, nobody!"; }

On IRC @adisbladis brought to my attention that to support more formats like TOML, we could use builtins.toJSON and convert that to toml with a build-time tool, meaning the generated strings won't be available to nix at eval time anymore and the generate functions have the signature generate :: Value -> Derivation. This doesn't seem like a problem: Nobody should need the raw Nix strings anyways, and this will speed up evaluation too.

I'd review it if it was written with terminal length in mind, but currently it's not feasible via github ui.

I'd review it if it was written with terminal length in mind, but currently it's not feasible via github ui.

this is useful https://github.com/StylishThemes/GitHub-code-wrap

An alternative that doesn't need any installations is to use the "Split" diff option. For whatever reason, it seems to wrap lines while "Unified" doesn't.

It should be noted in the docs that some of these functions may write to the store, which is not safe when Nix is handling secrets. This is in contrast to builtins.toJSON etc, which operate entirely in memory.

For NixOS modules at least it doesn't make much of a difference, because the only way for a string (which toJSON returns) to influence a system build is by putting it in a derivation. With the interface this PR adds, this step is just done a little earlier. But yeah it can't hurt to point this out, I'll add a note

@roberth Looking good now?

I wonder if pkgs-lib should be pkgs/lib to match nixos/lib.

Awesome, thanks for merging!

@Ericson2314 I intentionally didn't name it lib because it could easily be confused with pkgs.lib.

@infinisil you might want to update this documentation section as well https://nixos.org/manual/nixpkgs/unstable/#sec-generators
It seems out of date considering the new NixOS doc you added.

Actually reading lib/generators.nix it looks like it should be consolidated with the new formats option introduced here.