Parametrize templates

[srid]

Enrich nix flake init with parameters

• [x] Initial spec #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.:

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

Other considerations:

• [x] Should params be ordered, by using a list type, so the prompts appear in sensible order? #10
• [x] Add tags field; #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 https://github.com/NixOS/nix/issues/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,

https://github.com/flake-parts/templates/blob/440ec16afdffbea136ff88f7b940853a9a2d2aed/flake.nix#L33-L45

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 (https://github.com/NixOS/nix/issues/6241) mentioned in the flake-parts-cli RFC (https://github.com/flake-parts/cli/pull/1#discussion_r1660305408). 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 https://github.com/juspay/omnix/issues/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: https://github.com/juspay/omnix/issues/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