The NixOS Tools That Actually Make a Difference

comma — Run Software Without Installing It

nix-index — Find What Package Owns a File

nurl — Generate Nix Fetcher Calls from URLs

nix-init — Generate Full Nix Packages from URLs

nh — A Better CLI for NixOS, Home Manager, and Darwin

statix — Lint Your Nix Code

nix-direnv — Fast, Persistent Dev Shells

flake-parts — The Module System for Your flake.nix

hjem — Home File Management Without the Overhead

NixOS Options Search — Keep This Tab Open I run NixOS on three machines and I have the same set of tools on all of them. Not because I followed a guide, but because I hit the same friction points on each one and eventually fixed them the same way. This is that list. comma is the one I show people first. You put a , in front of any command, and it finds the right package in nixpkgs, pulls it in temporarily, and runs it. Nothing gets installed permanently. Nothing pollutes your profile. Under the hood it wraps nix shell -c and nix-index together. It also caches results: once you pick a derivation for a command, it remembers, and once the path is evaluated by Nix, subsequent calls are nearly instant. The benchmarks in the repo show cache level 2 is about 159x faster than cache level 1. That number is real. It requires a nix-index database to know where files live in nixpkgs. The companion project nix-index-database provides pre-generated databases on a regular schedule, so you can skip building one yourself. nix-index builds a local database by indexing the binary caches. Then you query it with nix-locate to find which nixpkgs package contains a specific file. The part most people actually use is the command-not-found integration. When you type a command that is not installed, your shell tells you the exact package to install instead of just printing an error. Coming from a traditional distro, this single feature makes NixOS feel less hostile. Building the index takes around five minutes. Or skip it and use nix-index-database for a pre-built one. Writing a fetcher call by hand means figuring out the right fetcher, the right attributes, and then computing a hash by actually downloading the source. It is annoying every single time. nurl takes a URL and an optional revision and prints a ready-to-use fetcher call with the hash filled in. It supports fetchFromGitHub, fetchFromGitLab, fetchFromGitea, fetchFromSourcehut, fetchCrate, fetchPypi, fetchhg, fetchsvn, and more. It avoids slow fixed-output derivations when faster alternatives exist. And it is the foundation that nix-init builds on. If nurl handles the fetching, nix-init handles everything else. Point it at a URL and it generates a complete package expression with hash prefetching, dependency inference, and license detection. All through interactive prompts with fuzzy tab completion. Supported builders: stdenv.mkDerivation, buildRustPackage, buildPythonApplication, buildPythonPackage, and buildGoModule. For Rust projects it infers the cargo hash automatically. For Python it picks up dependencies from PyPI metadata. The docs are honest about this: the output will probably need tweaks, and you should verify the license and description yourself. But it does the 80% that nobody wants to do manually, which is why packaging contributions happen at all. nh reimplements nixos-rebuild, home-manager switch, and darwin-rebuild with better output and a few genuinely useful additions. The shorter syntax is nice but not the point. When you run nh os switch, you get a build tree from nix-output-monitor, a diff of what is actually changing in your derivations, and a confirmation prompt before anything gets activated. You stop switching blind. nh clean extends nix-collect-garbage with gcroot cleanup, profile targeting, and time-based retention like --keep-since 4d. A NixOS module in nixpkgs can wire this up as an automatic service. statix checks Nix files for antipatterns and fixes the ones it can. It catches redundant pattern bindings, collapsible let...in blocks, manual inherit patterns, unnecessary boolean comparisons, unquoted URIs, and more. The full list is available via statix list. Specific lints can be disabled in a statix.toml at the project root, and it respects .gitignore by default. Plug it into your editor and forget about it. nix-direnv replaces direnv's built-in use_nix and use_flake. The built-in version re-evaluates on every shell entry, which gets slow. nix-direnv caches the result and only rebuilds when your shell.nix or flake.nix actually changes. The part I care about more: it pins the shell derivation in your Nix gcroots. Garbage collection will not delete your build dependencies. I lost hours of cached downloads to a nix-collect-garbage run before I started using this. Setup with Home Manager: Add use flake or use nix to .envrc, run direnv allow, and your environment loads automatically on cd. Works with classic shell.nix and flake-based devShells. Every non-trivial flake.nix eventually becomes a mess. Packages for multiple systems, devShells, CI checks, a NixOS module. You end up with 300 lines of forEachSystem repetition and nobody wants to touch the file. flake-parts brings the NixOS module system to flakes. You split the configuration into focused files and flake-parts assembles them. It handles the system boilerplate and makes it easier for others to pull your flake's outputs into theirs. Migration is gradual. Wrap your existing outputs in mkFlake and move things over piece by piece: Projects using it include nixd, argo-workflows, and hyperswitch. It has become a standard approach for flakes that need to stay maintainable. If you have ever wanted Home Manager's home.file without the rest of Home Manager, hjem is worth knowing about. Hjem ("home" in Danish) is a NixOS module that manages files in $HOME. That is mostly it. No program modules, no environment activation scripts, no opinion about your shell. You declare files and it links them into place using smfh, an atomic file linker backed by systemd services. It is multi-user by design. Each key under hjem.users maps to a user in users.users, and hjem refuses to manage homes for users that do not exist. The honest comparison to Home Manager: hjem does far less. It does not abstract away program configuration. There is no programs.git.enable equivalent. The project is explicit that application-specific modules are out of scope, though a separate project called hjem-rum is building that layer on top. I think that constraint is actually the point. Home Manager is large, occasionally opinionated in ways you did not ask for, and has a reputation for activation scripts that sometimes conflict with NixOS's own. Hjem is small enough that you can read the entire codebase in an afternoon. If all you want is declarative dotfile management wired into your NixOS config without pulling in a second module framework, hjem is the cleaner answer. It is still young at around 330 stars, so I would not call it battle-tested, but it is actively maintained and the scope is intentionally narrow enough that "mostly feature-complete" is a realistic claim. Not something you install: search.nixos.org/options. It searches the entire set of NixOS module options. Type, default value, which module declares it. When you cannot remember if it is services.nginx.enable or programs.nginx.enable, this is where you go. It is faster than reading source, and honestly faster than grepping nixpkgs. It also covers Home Manager options and has a package search tab. I have it open on every machine I work on. None of these are required. NixOS runs fine without them. But each one fixes something that is genuinely annoying without it, and after a while you stop noticing the friction because you stopped having it. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse