[pxc]

Yes, because it also makes your Nixpkgs config explicit (doesn't read ~/.config/nixpkgs/config.nix unless you source it in-repo) and doesn't rely on env vars (e.g., NIX_PATH) which are not given explicitly in the flake.

But pinning Nixpkgs alone does get you much of the way there (and for many use cases— those where the only referent on it is 'nixpkgs' or 'nixos'— does make NIX_PATH redundant anyway).

[Athas]

> But pinning Nixpkgs alone does get you much of the way there (and for many use cases— those where the only referent on it is 'nixpkgs' or 'nixos'— does make NIX_PATH redundant anyway).

What is missing compared to using flakes? The only `NIX_PATH` components I normally use is `nixpkgs` which hooks into the whole channel system (which is bad), but by settings my `pkgs` variable to a specific commit/tarball, I can ignore `NIX_PATH` entirely, right?

[pxc]

Traditionally you might also use NIX_PATH for secondary sources of packages and modules, like the Emacs overlay, NUR, or the Nix-Darwin repo.

But yeah if you pin all of your package sources and set your Nixpkgs config locally, you get all the benefits aside from the Nix evaluator's 'pure' mode, which gets some evaluation speedups due to caching.