In your specific case - a _channel_ versus a flake _input_ - consider how you're tracking your system configuration. If you have an /etc/nixos/configuration.nix, then your system can be reconstituted _only_ if you have that configuration.nix in addition to the revision that your channel is currently on. Compare this with a system defined in a flake's `nixosConfiguration`, which accepts its version of nixpkgs from the flake's input, so you can rebuild/recreate the system from the flake entirely without needing to piece together other bits of state like the current channel revision/nixpkgs checkout.
Is this more deterministic than pointing Nixpkgs at a specific commit/tarball in the configuration? I have often done this to make reproducible builds in other Nix settings and it has worked well.
It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock.
You can get almost all the benefits Flakes brings without Flakes using alternatives like niv.
> It is: using Flakes you're thrusted into a more pure evaluation mode by default, and it creates a (standard) artifact of the revision you're on: the flake.lock.
Can you name a specific example of the kind of nondeterminism/nonreproducibility I risk by simply pinning Nixpkgs itself (or to be more principled, using Niv)?
Certain environment variables at the time "nix-build" is executed can affect the nix configuration. Nix flakes default to ignoring those environment variables.
Flakes are also the way forward for pinning nixpkgs; it autogenerates a list of revisions used to pin, and allows easy updating. Flakes and niv, to a large degree, are about solving the same problem.
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).
> 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?
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.
