nixos/nixpkgs: add option to specify Nixpkgs source path

[rnhmjoj]

A non-breaking and (IMHO) simpler alternative to #333788 for setting the Nixpkgs versions declaratively from configuration.nix.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change (nixos-rebuild, nixos-rebuild-ng)
• Tested basic functionality of all binary files
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[thiagokokada]

Can't comment too much about the change itself since I use Flakes, but at least the nixos-rebuild-ng changes looks good to me.

Left a comment about the tests mocks but this is not a merge blocker.

[amozeo]

Hey, nixpkgs.source option in nixos is an interesting approach to pin nixpkgs for a given nixos configuration. I found several issues with your implementation of it.

I cannot review changes in nixos-rebuild-ng because I am not familiar with its code.

in nixos-rebuild.sh, there is also one more instance of getting nixpkgs from nix path in line 646 (after changes). I think you forgot about that occurence.

[amozeo]

I just noticed that there is option nixpkgs.flake.sources that tries to hold similar information as the option that you want to add, nixpkgs.source, maybe we want to deprecate it/change it/reuse it? doesn't look like it's used anywhere else in nixos module system except that file where is declared.

[rnhmjoj]

Hey, nixpkgs.source option in nixos is an interesting approach to pin nixpkgs for a given nixos configuration.
I found several issues with your implementation of it.

Thank you for reviewing!

in nixos-rebuild.sh, there is also one more instance of getting nixpkgs from nix path in line 646 (after changes). I think you forgot about that occurence.

Yes, I missed it because I was looking only for the angle brackets syntax.

[rnhmjoj]

I just noticed that there is option nixpkgs.flake.sources that tries to hold similar information

I think we should unify the two options.

[rnhmjoj]

I made an attempt to unify flakes and non-flakes options in 0fca667. The flake part is completely untested for now.

[thiagokokada]

nixos-rebuild-ng part LGTM, but not tested.

Also didn't review the other changes.

[infinisil]

I'm really not a fan of this. It's fundamentally impossible to make configuration.nix specify Nixpkgs and it be used consistently, you always end up with the same problematic cases, such as:

• A separate Nixpkgs is needed to "bootstrap" the eval, like the <nixpkgs> here. And this is not reproducible in general.
• Upgrades across Nixpkgs versions are problematic, because some module might not evaluate with both the older and newer Nixpkgs (the _module.check can't ignore everything)

The real solution is to abandon the idea of "configuration.nix can reproduce the system" and switch to "system.nix/flake.nix/default.nix can reproduce the system", where that entry-point file depends on configuration.nix. That's something that Flakes got right, and it's also the direction I've indicated with #333788. This way there's none of the above problems.

[RossComputerGuy]

Agreed, I kinda think of the non Flakes way as legacy and so large changes specific for it shouldn't be made. Flakes is the direction a lot of things are going and just manages it a lot cleaner.

[infinisil]

I don't necessarily agree with that. I don't want people to have to buy into Flakes just to have an eval-reproducible system. It's very easy to make something similar work in traditional Nix, it's not a large change.

[rnhmjoj]

It's fundamentally impossible to make configuration.nix specify Nixpkgs and it be used consistently

My initial proposal was to use callPackage (or similar) to fill in the arguments of configuration.nix and extract nixpkgs.source, without using evalModules. This works reliably with the only limitation that nixpkgs.source must not depend on any of the module arguments and be set directly in configuration.nix.

The real solution is to abandon the idea of "configuration.nix can reproduce the system"

Yes, but even then it's a letdown that you can't have a self-contained expression to describe a system reproducibly.
It means you'll never be able to just copy-paste, build and get the same system.

[infinisil]

Nah it's totally possible. With #333788, you can write a /etc/nixos/system.nix as follows:

let
  nixpkgs = fetchTarball { ... };
in
import (nixpkgs + "/nixos") {
  configuration = {
    environment.systemPackages = [ ... ];
  };
  # Or if you want to have the traditional `configuration.nix`:
  # configuration = ./configuration.nix;
}

And nixos-rebuild switch works.