Discussion: scfg generator semantics

[antonmosich]

#4650 introduced a new generator, toSCFG for the scfg configuration file format. This generator seems to work for all requirements senpai has, but lacks some features. While trying to implement a pimsync module (see #6810), I encountered the need to have a more complete scfg generator. I am very unsure about how this generator should work, as the scfg format e.g. doesn't care about duplicate keys.

The following code samples show how the current generator works:

home-manager/tests/lib/generators/toscfg-example.nix

Lines 5 to 31 in 5f217e5

	dir = {
	blk1 = {
	_params = [
	"p1"
	''"p2"''
	];
	sub1 = [
	"arg11"
	"arg12"
	];
	sub2 = [
	"arg21"
	"arg22"
	];
	sub3 = {
	_params = [
	"arg31"
	"arg32"
	];
	sub-sub1 = [ ];
	sub-sub2 = [
	"arg321"
	"arg322"
	];
	};
	};
	};

turns into

home-manager/tests/lib/generators/toscfg-example-result.txt

Lines 1 to 10 in 5f217e5

	dir {
	blk1 p1 "\"p2\"" {
	sub1 arg11 arg12
	sub2 arg21 arg22
	sub3 arg31 arg32 {
	sub-sub1
	sub-sub2 arg321 arg322
	}
	}
	}

We encounter a problem if we even try to write a config like the sample config from the documentation, see also this comment of mine.

One approach I considered was to keep the current _params pattern as-is and add the possibility to use lists of attribute sets to achieve a nix representation of the example like this:

{
  train = {
    _params = [ "Shinkansen" ];
    model = [
      {
        _params = [ "E5" ];
        max-speed = "320km/h";
        weight = "453.5t";
        lines-served = [
          "Tōhoku"
          "Hokkaido"
        ];
      }
      {
        _params = [ "E7" ];
        max-speed = "275km/h";
        weight = "540t";
        lines-served = [
          "Hokuriku"
          "Jōetsu"
        ];
      }
    ];
  };
}

I am very unsure whether this approach would work for every possible scfg, and would appreciate a few other heads thinking this through. As far as I can tell this would not even need to break existing senpai configs.

CC: @teto you said you'd review a pimsync PR. I haven't got that far yet, but would appreciate your feedback at this stage!

[teto]

I am not familiar with scfg apart from what I did with pimsync. I would say this depends on what you want to achieve.I mean you could bypass the scfg generator for a quick merge or scope its usage to the final blocks.

Ideally we want the generator to support all of the scfg specs: if the spec supports several blocks with the same name than choosing a top level dict is an error and it should be a list of for instance lib.nameValuePair ?

[antonmosich]

I really like the idea of using something like name value pairs, though maybe it would wise to have triplets (name, parameters, children to keep the naming from the specification repo) instead.

[teto]

use whatever you think is best. I mentioned nameValuePair because it brought some familiarity and the value could have been a submodule. If nameParamsValueTriplet (or whatever) makes more sense then go for it :)