@LnL7, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @ericsagnes and @nbp to be potential reviewers.

Very good to see this! I wished this existed several times in the past.

Since this mechanism is more general than replacing a module (it really just excludes a module), wouldn't it be better to substitute the name replaces with excludes or disables? Whether you use it for replacing a module is up to the user.

You can then optionally build a very light abstraction on top of this where the replacement is more obvious:

{
  replaces = [
    { old = <nixpkgs/nixos/modules/services/databases/postgresql.nix>;
      new = ./postgresql.nix;
    }
  ];
}

I didn't really give a good example, but the idea is that a custom module can declare what modules it replaces.

Ok you mean placing the replaces = [ ... ]; in ./postgresql.nix itself. Then the name makes more sense indeed. I guess I would still prefer a name which describes what operational effect it has instead of the intended application. However, I don't care that much about it.

Regardless of name, it would be cool to have this feature!

Using a fully qualified path to denote modules is unsound because there is no guarantee that <nixpkgs> points at the Nixpkgs tree used in the current evaluation. For example, if I do

nix-build /my/nixpkgs/nixos/tests/foo.nix -A test

then <nixpkgs> does not point at /my/nixpkgs. Similarly, in a multi-machine NixOps network spec, each machine could use a different Nixpkgs tree. (I don't think NixOps actually already supports that, but you get the idea.)

It might be better to have something that uses module filenames relative to the current Nixpkgs tree, e.g.

disableModules = [ "nixos/modules/services/databases/postgresql.nix" ];

(I wouldn't call it replaces because it doesn't actually replace a module.) The path of the current machine's Nixpkgs tree is available via config.nixpkgs.path IIRC.

I agree that it's not ideal to use the full path, but there doesn't seem to be reliable way get the path of pkgs, config.nix.nixPath doesn't update as far as I can tell.

I also noticed this behaviour, is that expected?

$ nix-instantiate --eval -I nixpkgs=/tmp/foo -E '<nixpkgs>'  # /tmp/foo
$ nix-instantiate --eval -I nixpkgs=/tmp/foo -E '<nixpkgs/nixos>'  # /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos

I think this will disable the correct modules when <nixpkgs> is not the active source of the nixos modules.

@edolstra

The path of the current machine's Nixpkgs tree is available via config.nixpkgs.path IIRC.

No, this is not an option, because this code solve the closure of the modules considered for the module system. So config.[...] is doomed to do an infinite recursion. This can only leave as a special attribute of the module system, and cannot be influenced by any mean by the evaluation of the configuration, like the imports.

@nbp Sorry, I mainly wanted to get some discussion started around this because I think this would be very nice to have in 17.03. Feel free to close this and push your changes if you want.

@LnL7 , also can you add tests cases for checking that disabledModules allow some to declare an option which would otherwise conflict, and to check that we can remove a definition as well. There is a test directory under lib which already contains module test that you can follow.

I added some basic tests and a better example for the manual. Anything else that's missing or should be improved?
@nbp Does the implementation using modulesPath look good to you or would you prefer something more like a searchpath for modules.

The question about disabling a single file vs the entire module closure is also still open. I don't really have an opinion about that.

Apart from that, there is at least a design question which needs to be answer, which is: should we consider the closure of the excluded modules or only a single module at a time?

To answer my-self. We only want to exclude a single module instead of the closure of modules, because the list of imports of a module can refer to common modules.

Counting the number of time a module is imported would be a nightmare to understand, and be a terrible interface.

Having to list all modules imported by the disabled modules would be painful but would at least be easy to understand as opposed to any automatic system decision.

@nbp ❤️ Thank you for all the help with this.

@globin , this change is marked as 17.03, we should either cherry-pick this change or move the release note to the next version.

I think I'd prefer not including this in 17.03 if you don't have strong feelings, to give this a period of time on master first.

I personally would really like see this in 17.03 because it enables more flexibility when using a stable release without having to maintain a fork of nixpkgs.
That being said it's often possible to work around it in some other way, like mkForce or renaming the module from unstable.

Reverted by commit fcec3e1

re-made by commit d88721e.

I would also prefer to see this in 17.03. In the documentation we can specify this is an experimental feature and that it's API might change in the future or that it might be removed. It's probably only going to be used by advanced users who know how to deal with changing API's.

Note that with #76857 disabledModules now works recursively, meaning any imports by any disabled modules are ignored.