Beauty

[aameen-tulip]

The design systems for Nix you've been cooking up recently are looking great.

I haven't tried out flake parts or std or similar systems yet; but the style you have here with interfaces and implementations split with modules to typecheck is really appealing.

In the future I'm hoping to carve out the time to explore these because it seems like it would save me from a lot of bespoke patterns I keep iterating through.

[blaggacao]

Since you mentioned std. I'm tinkering with an idea:

{
  inputs.std.url = "...";
  inputs.nixpkgs.follows = "std/nixpkgs";
  outputs = {std, self, ...}@inputs: std.growOn {
    inherit inputs;
    cellsFrom = ./nix;
    cellBlocks = with std.blockTypes; [
      # assumes ./nix/<cell>/packages.nix
      # to contain drv-parts modules
      (drvParts "packages" {ci.build = true;})
    ];
  }
  {
    packages = std.harvest self ["mycell" "packages"];
  };
}

Assuming a future implementation in dream2nix.

Standard BlockTypeActions implement useful UX (on the CLI & TUI & recently even CI) for known BlockTypes.

What stable output contracts could drv-parts and what output contracts would d2n provide for BlockTypeActions to consume and expose to the framework?