devos/profiles
Pacman99 115f1e6711 make core an unecessary profile and add to suites
Prevents mkHosts subverting standard devos api to import core and add
all necessary core features to mkHosts, so core can be safely deleted in
suites
2021-04-06 19:00:57 -07:00
..
core make core an unecessary profile and add to suites 2021-04-06 19:00:57 -07:00
README.md treewide cleanups and refactoring for initial tests (#157) 2021-03-14 07:10:51 +00:00

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.