So I tried to enable the KDE partition manager by installing (or rather, trying it out in a nix shell) kdePackages.partitionmanager, which didn’t work. Then I Googled and it turns out I had to enable the programs.partition-manager module by setting programs.partition-manager.enable = true; in my config.
How do I know when to use one or the other?
If you take a look at the module, you’ll see that it does very little. It adds libsForQt5.partitionmanager to your system packages (this was probably the one you were looking for), in addition to adding libsForQt5.partitionmanager.kpmcore to both system packages and registering it as a package for dbus. I’m not familiar with this package, but I assume there is some dbus integration required or at least recommended to make sure the program works properly.
Generally, the packages used almost always exist as standalone packages, although sometimes with unexpected names. Modules are usually created when there is extra configuration you need or should have in order to use the package. Extra configuration could be anything, but often you’ll see tmpfiles rules, linking stuff into etc, udev rules, enabling kernel modules, suid/sgid or capability wrapping, or assertions to warn you about incompatible configuration.
For service-like programs (usually under services), it’s a different story. The modules are usually a lot larger. They also usually run systemwide (in contrast to interactive programs meant use by multiple users from a shell), so it makes sense for their configuration to be a part of the nixos configuration.
As a rule of thumb for non-service modules, if there exists a module for the program, there’s probably a good reason for it, and 95% of the time you want to enable it to make sure everything runs smoothly. There are some exceptions however, with overly opinionated modules or modules that are only there to let you provide global config into etc (which you might or might not be interested in).
Check the manpage, mostly. man configuration.nix has all the nixos options. If there’s one for that program, you probably want to use it. You can also search options on this webpage if you prefer.
Probably not a helpful comment to solve the problem, but for context, and because I know many people asked the same question:
The way we talk about things in the Nix ecosystem is messy, for historical reasons:
What’s called a “package” is actually a mix of a derivation (essentially a function that will produce a file system tree) and some metadata, and will typically give you executables to run directly. Many executables need additional configuration however, sometimes so much that they will only make sense in a very specific context within the operating system.
This is what NixOS modules are for, which you can plug into your operating system configuration; they end up as part of one big derivation, where all the files are wired up such that the executables from the package derivations will do the right thing. This is particularly valuable for “services”, programs that run in the background.
What most people think of though when they want to use software is something like “application” or “project”. If you search for the “application” nginx, you’ll get the package (just the executable) or the service module (lets you configure how the executable is run in the background). Depending on the “application” you may need one or the other or both. Because of how things are, there’s not really a way to tell that in advance.
The historical reasons for that, as far as I can tell, is the fact that “packages” were there first, and modules were tacked on as an afterthought. Then the ecosystem grew organically without anyone really cleaning up the discrepancies, and then tools like the search page were built around it.
What I propose is turning our internal data structures inside out. We should orient things around “applications” as the main data structure, and attach all the necessary information to those, which would allow instructing users what to do. An example of what that may look like (structurally; it’s not supposed to be pretty yet) was prototyped for Summer of Nix, to showcase projects funded through NGI: NGIpkgs Overview