-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
mkRenamedOptionModule doesn't work in submodules #96006
Comments
cc @infinisil |
I've got a plan for fixing this! Will work on this soon probably :) |
See PR above ^ :) |
Still needed! |
For the record, this would be useful in https://github.com/nix-community/home-manager/blob/master/modules/misc/xdg-desktop-entries.nix where assertions are currently extracted from the submodules and shoved into top-level assertions. I wonder if the right solution would be to desugar This probably overlaps with the more general discussion around submodule syntax, e.g. #146882 (comment) |
It simply cannot be done, if signing continues to be a submodule and NixOS/nixpkgs#96006 continues to be a problem.
`mkRenamedOptionModule` has been used to throw warnings if the old option names are used, while still allowing for the old names to work. A warning is only thrown for 'vpnnamespaces' as the warnings apparently do not work for submodules. This might have something to do with NixOS/nixpkgs#96006
... 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.
Describe the bug
I'm working on a home-manager module, where I now want to rename
to
The problem is, that list of submodules.
I tried to add
to the
programs.firefox.profiles.<name>
module, but that causes the errorbecause each submodule doesn't have a separate warning system.
Obviously doing
doesn't work either, because it's missing the profile name.
To Reproduce
Try to rename a suboption in an option of type
types.attrsOf (types.submodule ({ config, ... }: {
.The error I got can be seen on my nur-packages' GitLab (on tag
nixpkgs-issue-96006
which I created for this occasion).Expected behavior
Unclear. I guess
warnings
would be propagated upwards, somehow, using magic?Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result."x86_64-linux"
Linux 5.7.16, NixOS, 20.09.20200821.4a87da1 (Nightingale)
yes
yes
nix-env (Nix) 2.4pre20200721_ff314f1
""
"nixos-20.09pre237781.32b46dd897a"
/nix/var/nix/profiles/per-user/root/channels/nixos
The text was updated successfully, but these errors were encountered: