lib, nixos: fix module aliases in presence of defaults

[oxij]

Before this change mkRenamedOptionModule would override option defaults
even when the old option name is left unused. For instance

{
  optios = {
    services.name.new = mkOption {
      default = { one = {}; };
    };
  };
  imports = [
    (mkRenamedOptionModule [ "services" "name" "old" ] [ "services" "name" "new" "two" ])
  ];
  config = {};
}

would evaluate to

{ config.services.name.new = { two = {}; }; }

when you'd expect it to evaluate to

{ config.services.name.new = { one = {}; }; }.

• All my configs build.
• Fits CONTRIBUTING.md.

Really /cc @edolstra and @nbp, since this touches the core.

[oxij]

Rebased.

[oxij]

Since @edolstra and @nbp ignore this and this is a pressing bug, as witnessed by #40434, may I kindly ask @vcunat and @7c6f434c to look at this?

[7c6f434c]

Looks OK to me but I happen to avoid using the module system, so I want to at least give a chance to more people to respond.

[nbp]

Since @edolstra and @nbp ignore this […]

Thanks for raising this in my ~24000 unread email by mentioning my name once more. I will have a look at it over the week-end. Feel free to also ping me on irc next Monday if you do not get any answer from me since.

[nbp]

I do not mind the changes, but I do mind about the use case.

Using mkRenamedOptionModule for non-option target will provide misleading documentation (Alias of <option>…</option>) suggesting that it exists a target option, which would not be documented anywhere.

I think you should fallback to manual handling of such renaming for such cases.

[nbp]

This should be fromOpt and not toOpt. We want to warn uses of the renamed option, not uses of the new option.

[nbp]

This sounds like mkAliasAndWrapDefinitions (setAttrByPath to) fromOpt ?

[oxij]

Thanks for a review!

This should be `fromOpt` and not `toOpt`. We want to warn uses of the renamed option, not uses of the new option.

Oops, fixed.

This sounds like `mkAliasAndWrapDefinitions (setAttrByPath to) fromOpt` ?

Yep.

I do not mind the changes, but I do mind about the use case. Using `mkRenamedOptionModule` for non-option target will provide misleading documentation (`Alias of <option>…</option>`) suggesting that it exists a target option, which would not be documented anywhere.

The use case is that you had an old option "foo" that now maps to "bar.foo", but "bar" has some other default value. It is uncommon thing to do, but when you have to do this (like for rspamd) current behavior is very confusing (and wrong). I read "alias of X" as "sets X to a given value when set", which is exactly what it now does, as opposed to "sets X to a given value when set, overrides the default either way", which is what it did before.

I think you should fallback to manual handling of such renaming for such cases.

I feel that would mean that every such use case would have to copy-paste pieces of this `doRename` across nixos (or do something even stranger like #40434 does, for example). Anyway, let's not merge this yet. I want to test the new fixed version (I'm pretty sure it should work, but better safe than sorry).

[oxij]

@nbp @7c6f434c Fixed, cleaned up, tested. It's perfect.

[oxij]

ping!

[oxij]

@nbp ping ping!

[oxij]

@7c6f434c may I ask you to merge this? @nbp is MIA and this is now stalled for 1.5 months and holds up rpamd internal milter support in nixos :(

[7c6f434c]

Do I understand correctly that mkRenamedOptionModule mentioned in @nbp's objection is simply no longer included? Because convenient GitHub is convenient and I cannot compare the original patch with the current state.

[oxij]

Do I understand correctly that `mkRenamedOptionModule` mentioned in @nbp's objection is simply no longer included?

No. The core of `mkRenamedOptionModule` is `doRename`, so @nbp's philosophic objection to my example in the commit message still stands. However, it is just a contrived example. It makes total sense in `rspamd` case where `services.rspamd.bindSocket` became `services.rspamd.workers.normal.bindSockets` and the latter suboption (`normal.bindSockets`) is an option in the submodule of `services.rspamd.workers` with `normal` being introduced in a default value. It makes total sense from the perspective of semantics of `rspamd` declarative configuration. Meanwhile, `master`'s implementation is clearly buggy because it doesn't do "option aliasing" ("set x when y is set") but something strangely different. In `rspamd`'s case, for instance, it always overrides the thing in the submodule even if the alias is never used. In any case, all this really changes is `x // setAttrByPath to (mkAliasDefinitions (getAttrFromPath from options))` to `mkMerge [ x (mkAliasAndWrapDefinitions (setAttrByPath to) fromOpt) ]` and some `let`s and indent.

[7c6f434c]

OK, I see. Yes, I agree it is easy to use for a misguided trick, but then again, I think that the entire module system is easy to misuse if that's one's goal…

[nbp]

@oxij Thanks for the patches and sorry for the delay.
You did the right thing by asking @7c6f434c to get it merge.