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, nixos: fix module aliases in presence of defaults #40418

Merged
merged 2 commits into from
Jun 27, 2018

Conversation

oxij
Copy link
Member

@oxij oxij commented May 13, 2018

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 = {}; }; }.

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

@oxij oxij requested review from edolstra and nbp as code owners May 13, 2018 01:33
@GrahamcOfBorg GrahamcOfBorg added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels May 13, 2018
@FRidh FRidh added the 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS label May 13, 2018
This was referenced May 13, 2018
@oxij
Copy link
Member Author

oxij commented May 26, 2018

Rebased.

@GrahamcOfBorg GrahamcOfBorg removed the 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS label May 26, 2018
@oxij
Copy link
Member Author

oxij commented May 29, 2018

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 7c6f434c requested review from fpletz, rycee and vcunat May 29, 2018 08:37
@7c6f434c
Copy link
Member

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
Copy link
Member

nbp commented May 29, 2018

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.

Copy link
Member

@nbp nbp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

lib/modules.nix Outdated
});
config = mkMerge [
{
warnings = optional (warn && toOpt.isDefined)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

lib/modules.nix Outdated
warnings = optional (warn && toOpt.isDefined)
"The option `${showOption from}' defined in ${showFiles toOpt.files} has been renamed to `${showOption to}'.";
}
(mkIf (fromOpt.isDefined) (setAttrByPath to (mkMerge fromOpt.definitions)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds like mkAliasAndWrapDefinitions (setAttrByPath to) fromOpt ?

@oxij
Copy link
Member Author

oxij commented Jun 7, 2018 via email

oxij added 2 commits June 11, 2018 15:06
Before this change `mkRenamedOptionModule` would override option defaults
even when the old option name is left unused. For instance

```nix
{
  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 = {}; }; }`.
@oxij
Copy link
Member Author

oxij commented Jun 11, 2018

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

@oxij
Copy link
Member Author

oxij commented Jun 17, 2018 via email

@oxij
Copy link
Member Author

oxij commented Jun 24, 2018 via email

@oxij
Copy link
Member Author

oxij commented Jun 27, 2018 via email

@7c6f434c
Copy link
Member

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
Copy link
Member Author

oxij commented Jun 27, 2018 via email

@7c6f434c
Copy link
Member

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…

@7c6f434c 7c6f434c merged commit b8ffd24 into NixOS:master Jun 27, 2018
@nbp
Copy link
Member

nbp commented Jul 8, 2018

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

@oxij oxij deleted the lib/fix-module-aliases branch November 18, 2018 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants