Using `flake-parts` to quickly render a Markdown / org-mode site

Guides
#1

Some of you are probably already aware of flake-parts which helps “modularize” flake.nix. This is especially useful on monorepos where the top-level flake.nix tends to get complicated and huge over time.

flake-parts can also be used to provide a nixos-module like feel.

For example, if you have a directory of Markdown or org-mode files, you can drop the following flake.nix to it, and run nix build to get a statically build website, or nix run to run a live updating view of those plain-text files.

{
  nixConfig.extra-substituters = "https://cache.garnix.io";
  nixConfig.extra-trusted-public-keys = "cache.garnix.io:CTFPyKSLcx5RMJKfLo5EEPUObbA78b0YQ2DTCJXqr9g=";

  inputs = {
    emanote.url = "github:srid/emanote";
    nixpkgs.follows = "emanote/nixpkgs";
    flake-parts.follows = "emanote/flake-parts";
  };

  outputs = inputs@{ self, flake-parts, nixpkgs, ... }:
    flake-parts.lib.mkFlake { inherit self; } {
      systems = nixpkgs.lib.systems.flakeExposed;
      imports = [ inputs.emanote.flakeModule ];
      perSystem = { self', ... }: {
        emanote.sites."default" = {
          path = ./.;
          pathString = ".";
        };
      };
    };
}

(This uses https://emanote.srid.ca/ to build/serve the site).

3 Likes
#2

And what is innovative about that use case? Couldn’t I already do that before just with different syntax?

#3

This part:

Because flake-parts is using the nix module system. It means that a flake can now impact the host flake output.

This is for scenarios where the host flake gets taken over by one of the input flakes. In a framework-like approach.

I prefer explicit wiring because it’s generally more composable. But I can see the appeal of the above approach if you want to reduce the amount of nix that your users need to know.

2 Likes
#4

So basically it ports the nixos module system to just flakes without nixosConfiguration.

1 Like
Hosted by Flying Circus.