c012f2f4ed
- [x] refactor lib into separate files, similar to NixOS/nixpkgs/lib. - [x] refactor ci to automatically generate derivations from flake outputs - [x] remove cluttered indirection statements throughout the codebase - [x] refactor hosts to allow for upcoming integration tests - [x] improve ambiguity in the existing docs - [x] add [BORS](https://bors.tech) support - [x] add initial integration test - [x] write tests documentation - [x] test lib - [x] improve version string generation, and do so automatically for pkgs/flake.nix sources Clean up the codebase as best we can in preparation for #152 and add tests. From now on, all PRs will be merged with BORS. |
||
|---|---|---|
| .. | ||
| core | ||
| README.md | ||
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.