Add a way to pin a NixOS version within the module system.

[nbp]

This modification add a way to re-evaluate the module system with a
different version of NixOS, or with a different set of arguments.

cc @garbas

[copumpkin]

@nbp does this also resolve #7467?

[nbp]

@copumpkin Yes, this solves #7467.

[copumpkin]

👍

[nbp]

The latest patch add documentation for the module and a changelog entry. The only remaining part is to add the test into the test infrastructure.

[nbp]

Ok, I tested the test case locally, and it works.
I did not do a VM test as this only check the evaluation of the module system.

review? @shlevy
feedback? @garbas

[shlevy]

@nbp Nice approach, looks good to me.

[henrytill]

Is this example correct?

[nbp]

No, this is a mix of 2 idea, I will keep the bottom one for now.

[domenkozar]

@edolstra

[copumpkin]

🍻

[garbas]

🤗

[offlinehacker]

nice, thanks :)

[vcunat]

Sounds useful 👍

[nbp]

These changes got reverted in commit d4636fa

[copumpkin]

@edolstra while in general the scopedImport mechanism can be similar, it's not quite the same:

1. scopedImport still (as far as I can tell) doesn't cache loaded .nix files, which can make it potentially quite a bit slower and less deterministic than regular import. Furthermore, implementing that memoization seems tricky.
2. If your entry point is just a configuration.nix, you don't control the actual entry point to evaluation (which is an implicit evalConfig wrapped up in nixos-rebuild somewhere), which leads to horrible hacks like my triple ### syntax for manipulating ~/.nix-channels in the EC2 (and soon other cloud providers) metadata processor. If we had something like this, we could kill the horrible ### stuff in our metadata and stay in pure Nix, which would also bring a few other advantages. The other place this applies is declarative containers, where we also don't currently have a clear entry point around evaluation of the modules. Note that I care about this because I want to version my modules just like I version my packages, so the various mechanisms like nixpkgs.overlays don't achieve any of this.

I don't know if this is the implementation we'll end up using, but do you agree that given the above this is at least something that's nice to have, even given the existence of scopedImport?

cc @grahamc given his interest in NixOS/nixops#649