Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib.modules.mkRenamedOption*: warn as eagerly as possible #360443

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

roberth
Copy link
Member

@roberth roberth commented Nov 30, 2024

... i.e. without adding any new strictness

This adds support for warnings in submodules.

Fixes #96006

To recap, #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.
  • [Reverted] Module-builtin assertions, disabling assertions and submodule assertions #97023 created data dependencies at submodule roots, not just toplevel

While something like #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.

TODO

  • more tests (this function did not have any tests in lib/tests/modules.sh)

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

... 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: lib The Nixpkgs function library 6.topic: module system About "NixOS" module system internals 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10
Projects
None yet
Development

Successfully merging this pull request may close these issues.

mkRenamedOptionModule doesn't work in submodules
1 participant