Co-authored-by: Anton <fetsorn@gmail.com> Co-authored-by: Chris Montgomery <chris@cdom.io> Co-authored-by: Timothy DeHerrera <tim.deh@pm.me> Reviewed-on: https://git.b12f.io/pub-solar/os/pulls/36 Co-authored-by: teutat3s <teutates@mailbox.org> Co-committed-by: teutat3s <teutates@mailbox.org>
2.2 KiB
Profiles
Profiles are a convenient shorthand for the definition of options in contrast to their declaration. They're built into the NixOS module system for a reason: to elegantly provide a clear separation of concerns.
Creation
Profiles are created with the rakeLeaves
function which recursively collects
.nix
files from within a folder. The recursion stops at folders with a default.nix
in them. You end up with an attribute set with leaves(paths to profiles) or
nodes(attrsets leading to more nodes or leaves).
A profile is used for quick modularization of interelated bits.
Notes:
Nested profiles
Profiles can be nested in attribute sets due to the recursive nature of rakeLeaves
.
This can be useful to have a set of profiles created for a specific purpose. It is
sometimes useful to have a common
profile that has high level concerns related
to all its sister profiles.
Example
profiles/develop/common.nix:
{
imports = [ ./zsh ];
# some generic development concerns ...
}
profiles/develop/zsh.nix:
{ ... }:
{
programs.zsh.enable = true;
# zsh specific options ...
}
The examples above will end up with a profiles set like this:
{
develop = {
common = ./profiles/develop/common.nix;
zsh = ./profiles/develop/zsh.nix;
};
}
Conclusion
Profiles are the most important concept in DevOS. They allow us to keep our Nix expressions self contained and modular. This way we can maximize reuse across hosts while minimizing boilerplate. Remember, anything machine specific belongs in your host files instead.