Shahar "Dawn" Or's Nix-powered "IT infrastructure" repository

This repository follows the dendritic pattern and happens to be the place in which it was discovered by its author.

This spares me of some boilerplate. For example, see termitomyces/imports module.

Nix files (they're all flake-parts modules) are automatically imported. Nix files prefixed with an underscore are ignored. No literal path imports are used. This means files can be moved around and nested in directories freely.

The following files in this repository are generated and checked using the files flake-parts module:

• README.md
• .github/workflows/check.yaml
• .gitignore
• LICENSE

I was once tempted to name them with great granularity, as to for example have flake.modules.nixos.fonts. Such granularity would result in a great number of named modules. One cost of such a pattern is that some imports lists would be longer than they need to be. Another cost is that when a new file is created, some more imports would typically have to be added to some of those lists.

For example, the flake.modules.nixos.pc module would have to import with config.flake.modules.nixos; [fonts ssh audio <...and many more>]. That's redundant; for one, the flake-parts module file in which for example flake.modules.nixos.fonts is defined is at modules/fonts.nix. Second, all modules that would import the flake.modules.nixos.fonts would also import flake.modules.nixos.audio. The pattern used instead is that modules/fonts.nix defines flake.modules.nixos.pc.

So what is the test for whether a certain set of option values deserves a distinct named module? It is whether that set of option values is to be imported in some configurations and not in others. An example of a set of option values that would deserve a distinct named module is flake.modules.nixos.laptop because it would be imported by laptop configurations and not by desktop configurations.

I attempt to maintain an upstream-first approach. While collaborating with upstream on the refinement and merge of those changes I maintain a branch of that input with those changes cherry-picked.

This repository is the origin of the input branches project which is used here.

What Nixpkgs unfree packages are allowed is configured at the flake level via an option. That is then used in the configuration of Nixpkgs used in NixOS, Home Manager or elsewhere. See definition at unfree-packages.nix. See usage at steam.nix. Value of this option available as flake output:

$ nix eval .#meta.nixpkgs.allowedUnfreePackages
[ "steam" "steam-unwrapped" "nvidia-x11" "nvidia-settings" ]

To help determine whether a Nix change results in changes to derivations, a package .#all-check-store-paths builds a TOML file that maps from .#checks:

default-shell = "/nix/store/9nx7s96vwz2h384zm8las332cbkqdszf-nix-shell"
"nixosConfigurations/termitomyces" = "/nix/store/33iv0fagxiwfbzb81ixypn14vxl6s468-nixos-system-termitomyces-25.05.20250417.ebe4301"
"packages/nixvim" = "/nix/store/p2rrqir5ig2v4wb3whvb8y0fmdc0kmhk-nixvim"

Running this repository's flake checks on GitHub Actions is merely a bonus and possibly more of a liability.

Workflow files are generated using the files flake-parts module.

For better visibility, a job is spawned for each flake check. This is done dynamically.

To prevent runners from running out of space, The action Nothing but Nix is used.

See modules/meta/ci.nix.

Some explicit flake inputs exist solely for the purpose of deduplication. They are the target of at least one <input>.inputs.<input>.follows. But what if in the future all of those targeting follows are removed? Ideally, Nix would detect that and warn. Until that feature is available those inputs are prefixed with dedupe_ and placed in an additional separate inputs attribute literal for easy identification.

This at the top level of the flake.nix file:

nixConfig.abort-on-warn = true;