Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
lib.modules.mkRenamedOption*: warn as eagerly as possible
... i.e. without adding _any_ new strictness This adds support for warnings in submodules. Fixes NixOS#96006 To recap, NixOS#97023 didn't make it because of unexpected infinite recursions. Context: - Attaching a warning to an expression can create an otherwise unnecessary data dependency, which can lead to infinite mutual recursion when a (typically very necessary) dependency exists in the other direction. - The `warnings` option is largely independent of the evaluation of the configuration, because it only reads from it. Nothing except `system.build.toplevel` reads from `warnings`. Not cyclical, everyone happy. - NixOS#97023 created data dependencies at submodule roots, not just `toplevel` While something like NixOS#97023 is a very general solution that would solve this `mkRenamedOptionModule` with ease, we don't need it for this particular problem. Specifically, in this case, we already have a data dependency where the new option has a definition based on the old option. So, we can attach the warning to the `mkIf` condition of that definition and make it trigger when the old option is about to be read anyway. As a side effect of this change, these particular warnings don't appear in the `warnings` option anymore. Maybe someone used those for testing, but `mkRenamed`* usages aren't really worth testing, so this is a small price to pay for support for renames in submodules.
- Loading branch information