Unlike a traditionally managed system, you manually keep an install list of all used system packages (including current version). It’s conceptually similar to how conventional package managers might have mirror a configuration list. Within this package list, you also specify options to configure for each package directly to the package manager (options which are exposed to Nix by whoever bundled that particular Nix package).

In other words: you’re treating packages as if they were configuration and then bundling the actual configuration into the same framework. This basically means that you can think of Nix packages as wrappers bundling the base software plus instructions for a config file generator. These generated config files are constantly getting regenerated, though, so in everyday use it’s usually best to abstractly think of them as nothing more than an interface between the Nix package manager and the software proper.

Worth mentioning at this point is the fact that the core Nix ecosystem is all about managing system-level software; Nix handles sudoer stuff and steers clear of interfering with user-level dotfiles. Using the hyprland wayland compositor as an example: you can see that the module only provides flags for things like NVIDIA patches and allowing xwayland – options for shadows/colors/animations are omitted entirely because they should (under the Nix philosophy) be configured with user dotfiles.

Now with that being said, Nix itself is merely a package manager, so it’s entirely possible to splash it in as a companion to your distro’s main package manager (similar to how you can globally install npm/pip packages). This is handy because Nix’s ecosystem is highly invested in enabling users to write their own packages (i.e.: Nix Flakes). In fact, some Nix users exclusively use it as a framework for creating and managing custom packages whenever the need arises to install something not provided in their distro’s package repository.

Of course, the most vocal Nix users are all-in and use NixOS. With NixOS, Nix is your native system package manager. Everything system-level is 100% Nix-based using NixOS, though the same leave-userspace-to-dotfiles philosophy still applies at the user level. This strategy enables cool stuff like seamlessly syncing your system environment between multiple workstations and having guaranteed safe system restore points through the use of nothing but a handful of config files.

Beyond that, for the total Nix freaks, there’s the Home Manager Nix package, which allows you to install and manage userspace applications Nix-style. This is handled separately from Nix/NixOS proper because user-space configuration is a much larger and faster-moving target. If you use Home Manager, it’s nigh-guaranteed that you’ll have to get your hands dirty by writing custom Nix modules in order to fully capture your userspace configuration. As you might imagine, this is a pretty big pain to do, though once you’ve put in the work all of your userspace installs & dotfiles will become super portable across all distros which support the Nix package manager (including Darwin).

Using NixOS options

By having the right configuration file there as part of the package’s options, like:

globalProgram.doFoo = true; or something like

globalProgram.extraConfig = "barCount=4567";