om init - for smart template generation

[srid]

Add

om init

This should support a registry of flake templates (use our various flake-parts modules), initialize them using nix flake init as well as fill in any user-specific content using the templateGenerators idea in flake-parts/templates#7 (comment)

The goal is to have om init create flakes for any kind of stack, eventually.

Implementation

To extend flake.templates, we can add:

{
  flake.templateGenerators.default = {
    # The generator to use (string or package)
    generator = "om init";
    # Arbitrary metaata (of the template) to pass to the generator.
    templates.default.params = {
    };
  };
}

Here, generator can be an arbitrary derivation (a function that takes pkgs and returns a types.package?) or it can be a string that represents the command line to use to invoke the generator? om init can fetch templates, and look for the special "om init" generator, in which case it can short-circuit by calling the necessary internal initializer function, passing the templates.?.params property as necessary.

Tasks

• Import flakreate repo #167
• flakreate: Import templates locally and use them #168
• Link om init to flakreate #169
• om init: Use om.templates for non-standard config #171
• Implement CLI test: om init: Flesh out CLI test #173
• template config: Upstream now or later?
  • Finalize the spec
• registry: Avoid flake.lock explosion, by switching to a JSON registry? om init: Faster registry loading using JSON cache #190
• ...

[srid]

cc @roberth (have I correctly understood your templateGenerators idea?)

[srid]

Alternatively, if we don't care about being general enough, we could just pass om configuration for templates as:

{
  templates.default = { ... };
  om.templates.default = {
    params = {
      # ...
    };
  };
}

This way, we don't have to fully spec out the general case first.

(Later, if a general spec does emerge, it should be straightforward to port the om.templates configuration to it).

See #153 for configuration seen from larger context.

[srid]

Regarding this, for MVP - let's keep the additional config in this repo, so it gives us some leeway to change things in future. Otherwise, we can consider this feature basically done.