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 a mirror configuration list. Within this list, you’re also sprinkling in individual package options which Nix will automatically apply for you (the options that Nix “sees” are manually coded in by whoever did the bundling of that particular Nix package).

In other words: you’re treating packages as if they were configuration and bundling that in with the actual configuration under a unified framework. This basically means that you can think of Nix packages as wrappers bundling the base software plus instructions for a config file generator. That’s effectively the “gimmick” of Nix: config files are routinely regenerated, so in everyday use they’re conceptually equivalent to an abstract 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 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 already 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 becomes Nix-managed, though the same leave-userspace-to-dotfiles philosophy still applies on the user level. This strategy enables cool stuff like seamlessly syncing your system environment between multiple workstations and having guaranteed safe 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 userspace configuration is a much larger and faster-moving target. If you use Home Manager to fully capture your userspace, it’s nigh-guaranteed that you’ll need to get your hands dirty by writing custom Nix modules. As you may imagine, this process can be a big pain… though it comes with the benefit of being able to seamlessly carry user applications & dotfiles across any distro that supports 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";