Nice. Could we call _module.assertAndWarn in the module system directly, so that assertions get triggered when evaluating the final config? (It seems like that's where assertions and warnings belong eventually)

Nice. Could we call _module.assertAndWarn in the module system directly, so that assertions get triggered when evaluating the final config? (It seems like that's where assertions and warnings belong eventually)

This is actually hard, because assertions and warnings tend to add strictness.

• We don't really know whether a config is supposed to be final or not. If it is final, we can add strictness, but otherwise it must remain lazy. Submodules tend not to be final, but even this is not a certainty, because the evalModules caller may interlink configurations.
• We don't know which submodules are meant to be checked, and which ones should be ignored.
• We don't yet have the means to find all the submodules and retrieve the assertions that are defined inside. We'd have to wire it through the type somehow, but types assume 1 return values, not a return value that must be split into two (config and _module)

For context, the discussion of such an attempt:

• [Reverted] Module-builtin assertions, disabling assertions and submodule assertions #97023

This came up again in nix-community/home-manager#3793 (comment)

Can we please just merge this

@infinisil The built-in idea is valid but hard and isn't going anywhere anytime soon, unless you commit time (I wish I could). Until then, this is the solution that people want use, and they'll be happy to migrate to something better when it comes along.
Note also that architecturally, the module functions mk*Module are coupled to this module.

TODO

• rebase
• add the module to lib.modules. lib.modules.modules.assertions?
• add to flake as .modules.generic.assertions?

Hit this again today, this time we wanted to mkChangedOptionModule settings.foo to settings.bar, where settings is an RFC 42-style submodule. This makes me think that this PR is not ideal, because it would pollute settings with warnings and assertions attributes that would have to be removed. I think those belong under _module as well.

Context: https://github.com/nix-community/home-manager/pull/4086/files#r1235087054

I guess another problem with mkRenamedOptionModules in freeformType submodules is that the old option is still left in the resulting config, so you end up with duplicates.

I think those belong under _module as well.

Removing them from config means that we'll have no way (as of yet) to retrieve them for independent evaluation.
Making the checks independent is crucial for avoiding infinite recursions, so without adding a new "out of band" data flow, laziness is in direct conflict with moving them into _module.

As for the reason why, here's a simple example,

settings: submodule, maybe with a freeformType
settings.foo: int
settings.bar: int
settings._module.assertions.foo_is_even: bool

Now a user defines

{ config, ... }: {
  settings.foo = config.settings.bar * 2;
}

So now foo depends on settings.bar, which depends on settings, which depends on the side effects of that submodule, which depend on foo, and that's an infinite recursion.

While you could argue that this situation is avoidable in one way or another, the problem is that the situation will occur, and infinite recursions are very hard to work with for users.

So if you want to have it in _module, you need to at least add a way to retrieve the checks outside of config, which means change the types submodule, attrsOf and listOf to pass _module around, or at least an attribute within it, and then change the options module argument to expose this to the modules.

Removing them from config means that we'll have no way (as of yet) to retrieve them for independent evaluation.

What do you mean? evalModules returns both the _module-free config and _module separately.

I guess another problem with mkRenamedOptionModules in freeformType submodules is that the old option is still left in the resulting config, so you end up with duplicates.

What if instead of returning the usual config from a submodule, we could make it return anything. We could make evalModules return { config = _module.return or config; }, such that an assertion module can come in and change things up as needed, ie set { _module.return = { config = removeAliases (config._module.filteredAttrs) config; check = runChecks config._module.checks; }; }.
A module could import that logic into the settings module and then do

config = mkIf cfg.enable {
  _module.checks = [ services.foo.settings.checks ];
  systemd.services.foo = fooService services.foo.settings.config;
}

My main objection with this is that it normalizes the in-band handling of checks, whereas I think handling them outside of config would be nicer.
Maybe treating the checks as first class is actually better, because at least it's not a weird special case where you have to go through options. It all depends on how well we could make the handling of checks through options and types work.

Should that stop us from implementing _module.return to unblock both of your use cases? I don't know.

• Automatically remove aliases from the config file value composably (filteredAttrs?)
• Implement checks|

I have to leave it at this for now, though I feel like I'm going to have to elaborate some things.

Removing them from config means that we'll have no way (as of yet) to retrieve them for independent evaluation.

What do you mean? evalModules returns both the _module-free config and _module separately.

It's more of a submodule problem, and it can be solved, but it's a non-trivial design problem, which is why the built-in assertion feature has been stuck for a long time.

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

https://discourse.nixos.org/t/the-module-system-is-dead-how-to-do-input-validation/30297/1

Why is the type for assertions types.listOf types.unspecified instead of something more specific?

Why is the type for assertions types.listOf types.unspecified instead of something more specific?

d5047fa updated the type but didn't model the item type. A submodule for the individual assertion type would be nice.

Can we get this over the finish line? I have multiple projects where I would like to import assertions.

Not sure whether this is the right approach.
With the built-in assertions PR, we learned that triggering the checks is a fine art (to put it simplistically).
By adding a checkAndWarn function to submodules, we make it very tempting to trigger it too early, which will lead to infinite recursions.
So I think the plan should be:

1. Merge lib.modules: init types checkAndMerge to allow adding 'valueMeta' #391544
2. Implement functionality akin to [Reverted] Module-builtin assertions, disabling assertions and submodule assertions #97023 but with better control of when and where the triggering happens (as late as possible)
3. Play around with it and document the patterns that work and the ones that don't.