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.

If you need guidance, a community branch is maintained to help get up to speed on their usage.

Constraints

For the sake of consistency, a profile should always be defined in a default.nix containing a nixos module config. A profile's directory is used for quick modularization of interelated bits.

Notes:

• For declaring module options, there's the modules directory.
• This directory takes inspiration from upstream .
• Sticking to a simple spec has refreshing advantages. hercules-ci expects all profiles to be defined in a default.nix, allowing them to be built automatically when added. Congruently, suites expect default.nix to avoid having to manage their paths manually.

Subprofiles

Profiles can also define subprofiles. They follow the same constraints outlined above. A good top level profile should be a high level concern, such as your personal development environment while the subprofiles should be more focused program configurations such as your text editor, and shell configs. This way, you can either pull in the whole development profile, or pick and choose individual programs.

Example

profiles/develop/default.nix:

{
  imports = [ ./zsh ];
  # some generic development concerns ...
}

profiles/develop/zsh/default.nix:

{  ... }:
{
  programs.zsh.enable = true;
  # zsh specific options ...
}

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.