- my own lib - nfh, it also contains a template to get you started
- well-known flake-parts
sh <(curl -L https://github.com/name-snrl/nixos-configuration/raw/master/install) <configuration-name>This is a modular structure designed to support multiple configurations
of different types without the need to write glue code, while still
remaining flexible. It primarily relies on an understanding of the
Nixpkgs module system
and its organization, and also uses nfh to simplify import management.
So, what’s the organization of Nixpkgs I’m talking about?
The nixos/modules directory in Nixpkgs primarily contains what can be called
classical modules: they declare options (interface) and define other options
(implementation) to realize the declared ones. These modules typically do
nothing, but provide an interface for the end user to configure complex things
in a simple way. All of them are imported in NixOS by default and together form
the set of options you use to configure your system (they are listed in the
NixOS search). Let’s call such modules
simply as a modules.
In addition, there are modules called profiles. They do not declare interfaces. Instead, they define options that implement the functionality of the given profile.
This repository uses the same definitions but adds another type called configurations. A configuration is the entry point where options are defined and profiles/modules related to that configuration are imported.
Let's take a look at the structure itself. Below is a trimmed output of the
tree command - it's not complete, but should be enough to give you an idea of
how this repository is organized:
│ # The flake mostly contains inputs. The only output it defines is
│ #`moduleTree`, generated by `nfh`. It also imports all files from
│ # modules/flake-parts directory, where all outputs are defined.
├── flake.nix
│ # Simple installation script that applies nix configuration from the target
│ # before starting the installation.
├── install
│ # This directory contains modules, profiles and configurations. Since
│ # different projects (NixOS, Home Manager, etc) often have incompatible
│ # options, the files are organized into subdirectories named after
│ # the projects they are intended to be used with.
├── modules
│ │ # A small set of profiles that are compatible with different projects,
│ │ # e.g. nix module provides nearly the same interface in both NixOS and
│ │ # Home Manager.
│ ├── common-profiles
│ │ └── ...
│ │ # Defines flake outputs using Flake Parts.
│ ├── flake-parts
│ │ │ # The most interesting module: it generates NixOS and Home Manager
│ │ │ # configurations based on the contents of `modules/*/configurations`
│ │ │ # directories.
│ │ ├── configurations.nix
│ │ └── ...
│ │ # Modules, profiles and configurations for Home Manager.
│ ├── home-manager
│ │ ├── configurations
│ │ │ │ # The Nix files in these directories define Home Manager
│ │ │ │ # configurations with the same names as the directories
│ │ │ │ # (configurations are defined for all systems).
│ │ │ └── ...
│ │ │ # Contains profiles that configure various aspects of the user env.
│ │ ├── profiles
│ │ │ └── ...
│ │ │ # Contains modules for Home Manager. Usualy, there is nothing here.
│ │ │ # But sometimes, if I'm developing a new module for upstream, it
│ │ │ # will appear here.
│ │ └── ...
│ │ # Modules, profiles and configurations for NixOS. It has exactly the
│ │ # same structure as the home-manager directory above.
│ └── nixos
│ └── ...
├── overlays
│ ├── gateway.nix
│ └── overrides.nix
└── pkgs
│ # Similar to `pkgs/top-level/all-packages.nix` in Nixpkgs, I don't see
│ # any reason to use by-path design for small package set.
├── default.nix
└── ...TODO