Make NixOS available first-class in NixPkgs

[roberth]

Issue description

Building a NixOS configuration from a Nix expression is already possible, but the way the user should do it is non-obvious, hacky and error prone. (See 'Technical details')
I suggest we define a top level function in NixPkgs called nixosConfig.

As this is relevant to the overall architecture, I would like to know the opinion and advice of @edolstra and @nbp

Note that /pkgs currently only imports /nixos at

nixpkgs/pkgs/desktops/gnome-3/installer.nix

Line 6 in 69698ec

module = ../../../../nixos/modules/installer/cd-dvd/installation-cd-graphical-gnome.nix;

Technical details

The user is currently faced with the following choices:

• How to import? import <nixpkgs/nixos> or import (pkgs.path + "/nixos")
• Which file to import? /nixos or nixos/lib/eval-config.nix
  and the following opportunities for mistakes:
• system argument
• pkgs argument

Design

I suggest we define a function pkgs.nixosConfig that is a small wrapper around nixos/lib/eval-config.nix. Its responsibility is to

• insert the right pkgs into the new NixOS configuration
• override any impure inputs to eval-config.nix, like the system parameter (builtins.currentSystem)

Implementation

The following definition works for my application in an overlay, but can probably be improved.

nixosConfig = { modules, system ? super.system, baseModules ? null }:
  import (super.path + "/nixos/lib/eval-config.nix") ({
    inherit system modules;
    pkgs = self;
  } // (if baseModules == null then {} else { inherit baseModules; }));

I'll make a PR if you think this is a good idea.

[roberth]

@williammpratt, That was a little unexpected, but thank you for your feedback.

• The creation of this issue was in good faith, to improve the quality of nixpkgs.
• I have followed the guidelines for contributing.
• I understand now that '@'-mentioning these community members is not desirable at this stage.

I am not just saying this to defend my actions, but to point out a minor flaw in the process here. You've pointed out the need for documentation. I will also check the RFCs (and issue tracker) to help improve the community processes' documentation and reduce this kind of friction for maintainers and future contributors.

[edolstra]

I have blocked williammpratt, who appears to be the latest incarnation of a user we've blocked several times before for making abusive comments in NixOS repositories.

@roberth Please don't be discouraged by williammpratt, who doesn't speak for any NixOS contributors.

[dhess]

Personally I would love to see more "special" functions like eval-config.nix exported via pkgs or lib. I end up importing them via <nixpkgs/...> quite a bit in my own configs, and that has the problem of being tied to NIX_PATH when I'm trying to move everything to a project-wide "pinned" Nixpkgs.

[roberth]

What a shame. Thank you Eelco. I will polish and document the thing and open a PR tomorrow.

[nbp]

@roberth Thanks for opening this issue. This is definitely a great idea!
I can foresee such expression to have multiple outputs such as a system-output / vm-output / ...

[roberth]

@nbp, I've made a pull request, #32422