Web-Projects/blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update the blog flake submodule and Nix Blog post

Browse Source
This commit is contained in:
Danila Fedorin 2022-04-09 15:55:05 -07:00
parent e778b8710d
commit dc3f086b9d
3 changed files with 24 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
code/blog-static-flake

@ -1 +1 @@
Subproject commit f2bb36b862b7c730c42abb0b759ddd3c1c4f3d4b
Subproject commit 67b47d9c298e7476c2ca211aac5c5fd961637b7b

2
config-gen.toml
View File

@ -4,7 +4,7 @@
url = "https://dev.danilafe.com/Advent-of-Code/AdventOfCode-2020/src/commit/7a8503c3fe1aa7e624e4d8672aa9b56d24b4ba82"
path = "aoc-2020"
[params.submoduleLinks.blogstaticflake]
url = "https://dev.danilafe.com/Nix-Configs/blog-static-flake/src/commit/f2bb36b862b7c730c42abb0b759ddd3c1c4f3d4b"
url = "https://dev.danilafe.com/Nix-Configs/blog-static-flake/src/commit/67b47d9c298e7476c2ca211aac5c5fd961637b7b"
path = "blog-static-flake"
[params.submoduleLinks.serverconfig]
url = "https://dev.danilafe.com/Nix-Configs/server-config/src/commit/98cffe09546aee1678f7baebdea5eb5fef288935"

36
content/blog/blog_with_nix.md
View File

@ -116,7 +116,7 @@ Do I really want to specify the `publicPath` each time I want to describe a vers
What about `settings.replaceUrl`, or the source code? Just like I would in any garden variety language,
I defined two helper functions:
{{< codelines "Nix" "blog-static-flake/lib.nix" 25 46 >}}
{{< codelines "Nix" "blog-static-flake/lib.nix" 25 48 >}}
Both of these simply make a call to the `website` function (and thus return derivations), but they
make some decisions for the caller, and provide a nicer interface by allowing attributes to be omitted.
@ -255,24 +255,32 @@ which is just `nixpkgs`. The `flake-utils` flake provides some convenient functi
flakes, and `katex-html` is my own creation, a KaTeX-to-HTML conversion script that I use to post-process the blog.
So what outputs should this flake provide? Well, we've already defined a NixOS module for the blog, and we'd like
our flake to expose this module to the world. This is the exact purpose of the `outputs.nixosModule` attribute.
It's sufficient to simply import the module file:
our flake to expose this module to the world. But the module alone is not enough; its configuration requires a list of
packages created using our builders. But where does one procure such a list? The caller will need access to the builders
themselves. To make all of this work, I ended up with the following expression for my `outputs`:
{{< codelines "Nix" "blog-static-flake/flake.nix" 28 28 >}}
{{< codelines "Nix" "blog-static-flake/flake.nix" 21 34 >}}
This is great, but it's not enough. Specifically, the module configuration requires a list of
packages created using our builders. But how should the NixOS configuration even reference these builders?
There's no "standard" way for exposing a pure function from a flake (as far as I know), but the good news is that
if you add a non-standard attribute to the flake, it will be accessible from wherever it is imported.
Thus, I simply provide a `buildersFor` function:
The flake `output` schema provides a standard option for exposing modules, `nixosModule`. Then,
exposing my `module.nix` file from the flake is simply a matter of importing it, as on line 31.
There is, however, no standard way for exposing a _function_. The good news is that any
attribute defined on a flake is accessible from code that imports that flake. Thus, I simply
added a `buildersFor` function, which, given an operating system, fetches the `nixpkgs` collection
and LaTeX builder script for that system, and feeds them to the file that defines the `english`
and `russian` builders. This `buildersFor` function also provides the builders with the two
different blog sources they reference, `blog-source` and `blog-source-localized`.
{{< codelines "Nix" "blog-static-flake/flake.nix" 23 27 >}}
The `system` parameter to `buildersFor` is necessary because the set of packages from `nixpkgs` depends on it. Thus, if the
builders use any packages from the collection (they do), they must know which system to pull packages for.
This is a common pattern in flakes: the `packages` attribute is typically a system-to-package mapping, too.
The `nixpkgs` flake requires a `system` argument, which means that the builders themselves
(which depend on packages from `nixpkgs`) need to be aware of what system they're being used for.
This is why `buildersFor` is itself a function.
Finally, the last little bit on lines 32 through 34 defines a default package for the flake. This
is the package that is built if a user runs `nix build .#`. This isn't strictly necessary for my purposes,
but it's nice to be able to test that the builders still work by running a test build. The
`eachDefaultSystem` function generates a `defaultPackage` attribute for each of the "default"
operating systems, so that the package is buildable on more than just my server architecture.
{{< todo >}} This needs to be done {{< /todo >}}
And that's it for the blog flake! I simply push it to Git, and move on to actually _using_ it from elsewhere.
#### Using the Module