Parametrize templates

[srid]

Enrich nix flake init with parameters

• Initial spec Enrich nix flake init with parameters #5
• Final spec, based on feedback (@roberth, etc.)

Considerations for parameters

Currently, the parameters introduced in #5 do a simple placeholder replacement across files (content & filename). But we may also need other kinds of substitutions, viz.:

• Do we need boolean type? Add boolean parameter #9
  • e.g.: "Add VSCode settings?" -> YES means .vscode/* is included in the generated folder. Same for .github/workflows and such. Real-world case: feat: Add haskell-template #8

Other considerations:

• Should params be ordered, by using a list type, so the prompts appear in sensible order? Make params a list, to preserve order #10
• Add tags field; Add tags property to templates #11

[roberth]

Not sure if reinterpreting .templates is a good idea.
What if we had a module that exposes two flake attributes,

• templates for nix flake init compatibility
• templateGenerators for flakreate, containing a rich specification and functions that create the template
  the generation logic could be evaluation based (needing Add builtins.toDir NixOS/nix#3497), or derivation based (a bit slower, but more powerful)

Ultimately though, I think the solution isn't templates but "actions" that change an existing configuration. That way you start with a basic flake parts flake, and run a tool that can make various additions to it, or just add new module files to keep it simple.
They'd be a lot like templates, but unlike templates, you can use them in an automated way after you've initialized a project.
The initial template could write a mkFlake with imports from builtins.readDir ./nix/flake, and subsequent actions could write to new files in that directory and/or the rest of the project. This limits the amount of syntax tree editing to the flake.nix inputs, where something fairly simplistic could get the job done. All the other composition is handled by the module system.

[srid]

@roberth Just coming back to this. Do you know how the templateGenerators thing would concretely look like?

Instead of the following, for example,

templates/flake.nix

Lines 33 to 45 in 440ec16

	templates = rec {
	nix-dev-home = inputs.nix-dev-home.templates.default // {
	tags = [ "home-manager" "juspay" "development" ];
	params = [
	{
	name = "Username";
	help = "Your username as shown by by $USER";
	default = "runner";
	required = true;
	files = [
	"flake.nix"
	];
	}

what would the new templateGenerators-based flake look like?

---

{
  templates.nix-dev-home = inputs.nix-dev-home.templates.default;
  templateGenerators.nix-dev-home = ...;  # What's this?
}

I feel like there's some overlap with your nix dev idea (NixOS/nix#6241) mentioned in the flake-parts-cli RFC (flake-parts/cli#1 (comment)). What if flake-parts-cli itself provided a subcommand (i.e., "run arbitrary project-specific command") that did this initialization? It would be no different to any other subcommand, like one for autoformatting project tree.

Is this something we can implement today as part of flake-parts-cli (and potentially upstreamed, in some capacity, to nix in future, as part of nix dev perhaps)?

[srid]

what would the new templateGenerators-based flake look like?

Posted a concrete idea juspay/omnix#152

Note: github:juspay/flakreate will be subsubed under github:juspay/omnix (which may also use flake-parts-cli at some point in the future).

[srid]

Okay, I think this templateGenerators proposal sounds interesting, inasmuch as it can be upstreamed. Then, we can have a concrete generator in omnix, which I'm working on as part of: juspay/omnix#152

Since templateGenerators probably won't be in upstream anytime soon, I'll go ahead with a custom implementation in om init for now. But once upstreamed, we can switch om init to use the new nix flake init obviously.

[srid]

I'll go ahead with a custom implementation in om init for now.

https://omnix.page/om/init.html#spec