Skip to content

Latest commit

 

History

History
44 lines (34 loc) · 1.91 KB

README.md

File metadata and controls

44 lines (34 loc) · 1.91 KB

Design Considerations

Imports

Guidelines for importing files within the hosts directory

  • Only importing downwards. This means no imports = [ ../../foo/bar/some-module.nix ]; - this is a classic pattern in NixOS configurations, but only gets more out of hand in time.
  • Only one level of imports. Which means imports = [./foo.nix] is fine, but imports = [ ./foo/bar/baz.nix ] is not.
  • Do not import defined modules outside hosts/default.nix. Meaning hosts/enyo/default.nix cannot have ../../../modules/.. in its configurations.

Module System

Guidelines for using the local module system for enabling or disabling services and programs

  • Hosts should properly define their type and equipment. This means adequately defined device.type, device.cpu and device.gpu at the very least
  • A host should contain at least 2 files/directories: modules/ and default.nix importing the rest of the files
    • modules/ should follow my local module system: config.modules.{device,system,usrEnv,theme} where applicable
    • default.nix may not contain anything other than an imports = [ ... ] importing rest of the files
  • Additional host-specific configurations may either go into system.nix (e.g. kernel configuration) or have their own file (i.e Wireguard or hardware mount configurations) with their own file (i.e mounts.nix)

Per-host hardware

Guidelines for using hardware-configuration.nix

Previously I have required hardware-configuration.nix to be available (under the name hardware.nix) for each host. This is no longer a requirement as almost all host-specific hardware configuration have been moved to hardware mixins located in modules/.

This further reinforces the requirement for the local module system, meaning hosts must specify things like CPU vendors or hardware specific kernel modules under modules.device or modules.system.