Introduce types.raw

[infinisil]

Motivation for this change

• Introduce types.raw as a type that doesn't do any nested processing for mkIf, mkForce, etc. on its values. This is useful when this processing would throw errors or where it would be too expensive (such as with package sets like nixpkgs).
• Use types.raw for _module.args's type. This finally fixes _module.args.name gets merged on assignment #53458

This is split off from #132448. This is also motivated by wanting to deprecate types.attrs and types.unspecified, for which types.attrsOf types.raw and types.raw (or types.anything) is an adequate general replacement.

Things done

• Wrote and ran tests
• Wrote docs

[roberth]

Not sure.

Is this the only use case?

[roberth]

I don't think this is the right trade-off. It's already lazy and when you do access an attr value, like that of pkgs, you'll force it anyway. Checking its type attr before returning it is a cheap and one-time operation.

[roberth]

OfBorg just finished. Allocations are down by 0.0002%

https://github.com/NixOS/nixpkgs/pull/160489/checks?check_run_id=5236802082

[roberth]

So I don't think we should trade the ability to mkForce in _module.args for arguably no benefit.

[infinisil]

See #160489 (comment), mkForce and co. still work on the spine

[roberth]

I must have read too much into "raw".
The tests demonstrate it clearly.

Perhaps the docs can clarify that it's not entirely raw?

[infinisil]

I guess the confusion comes from #132448 where types.raw originally worked like that, not doing any processing at all, but I changed that after discussing it with you :)

I think mentioning that in the docs is a good idea

[infinisil]

@roberth This type still works with mkForce, mkIf and co., just not deeply. E.g. this works and gives a result of 30:

let lib = import ./lib; in

lib.evalModules {
  modules = [
    {
      options.foo = lib.mkOption {
        type = lib.types.raw;
      };

      config.foo = lib.mkMerge [
        (lib.mkIf false 10)
        20
        (lib.mkIf true (lib.mkForce 30))
      ];
    }
  ];
}

types.anything is similar to types.raw in that it accepts any value, however types.anything recurses deeply into the structure to apply any mkForce and co. And that is what makes types.anything very unsuitable for below-described use cases.

The main use case for types.raw is values that aren't meant for the module system to be evaluated and merged, because they come from outside the module system. So e.g. things like package sets, which have their own merging strategies incompatible with the module system: overlays, overrides, extends, etc. The module system also shouldn't try to inspect these values for any mkForces and co, which would make it excessively strict in evaluation without any benefit, since you won't be using mkForce and co. for e.g. pkgs.hello

Other than _module.args I can also think of nixpkgs.pkgs and options like services.xserver.windowManager.xmonad.haskellPackages that could benefit from this.

We also need to deprecate types.unspecified due to its implicit and arbitrary merging behavior, and replace it with either types.anything or types.raw.

[roberth]

Is this the only use case?

This one seems valid.

#157056 (comment)

[roberth]

I think what's important is that

• it doesn't merge or check
• it does apply priorities
• it should be used if and only if merging and checking are not desirable

"Especially useful" and "recommended" are a bit too encouraging for something that should be applied with attention.

[infinisil]

Sounds good, I updated the docs

[infinisil]

@roberth Does this sound good?

[ncfavier]

As expected, this broke my config because I was adding my own stuff to _module.args.utils. What was less expected is that instead of a module system error I got an infinite recursion (logs).

Probably just a "me" problem not worth looking into as I couldn't reproduce that error on a minimal config.

[roberth]

I'd like utils to be removed, as it is nonsensical.

[ncfavier]

Yeah, I guess it's supposed to be a middle ground between lib and pkgs? Maybe the things it defines should go into config.lib instead?

[roberth]

As a general rule, utils is the name for the place people create to put the stuff they don't know where to put. config.lib is only slightly better.

The systemd logic can move into importable modules instead, after #156533

[nixos-discourse]

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

https://discourse.nixos.org/t/tweag-nix-dev-update-25/18003/1