This seems like a very bad change in terms of usability, especially for "normal" users, in return for faster evaluations that favor the power users. The 1%! 😋

Being able to just set services.nginx.enable = true; is so magical it's-- it's on of the top things I use to sell people on NixOS.

I'm optimistic that we can accomplish your goals (and wow these changes really do reduce resource usage!) without negatively impacting normal use.

My other concern is that in the current world all modules are evaluated -- which kinda means they are always evaluate-able. Maybe I overestimate the benefit of that, but it seems this change might make it easier for modules to bitrot badly without anyone noticing.

There is the related problem of backwards compatibility as well, I suppose.

One solution to most of these is to make your suggested changes "under the hood" but by default still include "all" modules. Unless user indicates they want to "roll their own"-- which many may elect to do, myself included-- with a flag or something in the configuration?

Finally I would say that I don't see a fundamental reason including all modules should be so bad, since (for an example) an order of magnitude improvement in the evaluator would very likely eliminate this problem almost entirely. There just aren't that many modules and the growth is linearish.

I'm not saying we can achieve that sort of improvement, but I think it's a touch misleading to say evaluating all modules is inevitably a problem-- there's not an unlimited supply of useful modules. But improving the evaluator is really hard.

This looks like good cleanup we should do anyway, and practically speaking does show huge improvements that are certainly worth pursuing. Hopefully we can have our 🎂 and eat it too.

Whoops I see

For compatibility, we can provide a all-modules.nix that imports all modules

Which is where I ended up too. Hmm, well I'll re-read and think some more. :)

I think that unresolved question @teh mentions raises an interesting point: we could do something like this for isolating modules rather than performance, an argument I find more compelling.

The module system currently allowing anything to affect anything else is great for easily adding functionality in new modules, it's not so good for reasoning about the interactions between modules after the fact. Perhaps the tension between flexibility and encapsulation is fundamental, and given the general insanity of the underlying Unix userland itself, the module system errs in the right direction. But I'd want to make sure of that first.

Could conditional imports be possible instead ? So far there is no mkIf-like thing for imports, but if there was, we could define all enable options together in some file and only import those modules that have enable = true. Thus we would have both discoverability and less files to parse.

@Ericson2314 Yes, the fundamental flaw of the module system is that any module can change anything (i.e. they violate the principle of least authority). But replacing the module system with a more functional approach is a much more significant undertaking which is out of scope of this RFC.

@dtzWill Is writing imports = [ nginx.nix ]; to enable Nginx less magical than services.nginx.enable = true? In any case, that's what you have to write anyway for out-of-tree modules, and I think we should move to more out-of-tree modules anyway (we can't expect everybody to have commit access to the Nixpkgs repo).

Would it not be possible to make the module loading lazy?

{
  myModule = mkLazyModule ./my-module.nix {};
}

Such as myModule.enable = true would load the rest of the module?

That would add a bit of evaluation overhead for each module but since most modules are not used it would lower to overall evaluation time. There is only a subset of modules that use the .enable pattern but I think it's a good thing to move towards that approach anyways.

… and I think we should move to more out-of-tree modules anyway (we can't expect everybody to have commit access to the Nixpkgs repo).

If that leads to a very well maintained list of core modules and a secondary list of community managed modules, that could be a good step.
I’m very vary of the possibility that everything but the core modules is going to become an ever bigger mess than it already is inside the monorepo (where you can’t even build if options are missing or have changed).

Would it not be possible to make the module loading lazy?

That might lead to strange patterns, where enabling some module could lead to a type error in another part of the repo. Since module errors already are very much non-local that could lead to a major decrease in usability.
At the very least the modules would have to be strictly evaluated on hydra (to catch such problems), so nothing gained.

That might lead to strange patterns, where enabling some module could lead to a type error in another part of the repo. Since module errors already are very much non-local that could lead to a major decrease in usability.

All the lazy modules would be enabled during document generation, which would surface that kind of incompatibility. Another thing I would like to see happen is to enforce the namespace extension such as a module can only define new config option below a specific namespace.

I agree we should not import all modules, so I definitely like to see this.

Such as myModule.enable = true would load the rest of the module?

Not sure whether that is possible, but we could move that flag out:

enabledModules = [
  "networking.networkmanager"
  <nixpkgs/nixos/modules/config/pulseaudio.nix>
]

This is basically just imports = [ ... ] but it also allows using strings for modules that are included in Nixpkgs. We just need to maintain a mapping then (replacing modules-list.nix).

Each module can define a requiredModules = [] which accepts the same values as enabledModules.

By the way, if there were a large list of enable options (only) in a single file, and enabling would include the real implementation and define the rest of options (a move in the direction of Nixpkgs structure, I guess) — would this help?

Since everything is global it's currently not possible to make imports conditional. The fact that a module is imported could influence the condition so you end up with recursion.

Also, a giant list of .enable options would not be very modular.

A good start would be to map the nixos options back to a file hierarchy. For example: services.xserver.enable = true; should have a file in either:

• nixos/modules/services/xserver/enable/default.nix
• nixos/modules/services/xserver/default.nix
• nixos/modules/services/default.nix

Once we have that in place we could then create a new module system under a new ./nixos-zero prefix for example that resolves things differently.

This RFC should be postponed until we have the flake mechanism, because that should make it a lot easier to have dependencies on other repos and split up Nixpkgs. Most modules in NixOS could be moved into separate flakes living in their own repositories. So for example, my NixOS configuration would have a dependency on the dwarffs flake (and maybe on an xserver flake, though perhaps that's too central to NixOS to move into a separate flake).

Let's close this RFC then as it will take a different form once flake is implemented

👍

What is the 'flakes' mechanism? Could it be linked here for people getting on this page later?

https://github.com/nix-community/flake.nix

This seems to be where the actual info is.

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/minimal-set-of-nixos-modules/2328/2

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/writing-modules-for-nur/2520/6

Seems like there is some work in this area over at https://github.com/tweag/nix/blob/flakes/src/libexpr/primops/flake.hh :-)

more information about the ongoing implementation of Nix flakes: https://gist.github.com/edolstra/40da6e3a4d4ee8fd019395365e0772e7

I've done some work on this in NixOS/nixpkgs#148456, adding the flexibility to use part of NixOS for configuring images and allowing to avoid the messy nixpkgs invocation module for example.

NixOS/nixpkgs#153211 is the first non-PoC PR. It allows experimentation with a minimal module list, refactoring towards the goal of this RFC, without breaking regular NixOS.

NixOS/nixpkgs#155892 unit-tests etc using a minimal module list.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/restructuring-nixos-to-work-without-systemd-e-g-with-sysvinit/21298/42

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-08-08-nixpkgs-architecture-team-meeting-42/31454/1