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: Change mkAliasOptionModule to use the priority for the alias #54528
lib/modules: Change mkAliasOptionModule to use the priority for the alias #54528
Conversation
…lias. This commit changes the `mkAliasOptionModule` function to make sure that the priority for the aliased option is propagated to the non-aliased option. This also affects the `mkRenamedOptionModule` function in a similar fashion. This also removes the `mkAliasOptionModuleWithPriority` function, since its functionality is now subsumed by `mkAliasOptionModule`. This change was recommended by @nbp: NixOS#53397 (comment)
This is so I can run tests with ofborg. For instance I'd like to be able to run the tests affected by this PR: NixOS/nixpkgs#54528
This pull request has been mentioned on Nix community. There might be relevant details there: |
@nbp Would you be able to take a look at this? It might be nice to get this in for 19.03. |
I just discovered this stuff in the lib, noticed it was introduced in #53397, but I don't understand the use case for `withPriority = false`.
Having read the aforementioned thread I still don't understand what is going on here, wasn't it just a bug that `mkAliasOptionModule` didn't copy the priority? Shouldn't `mkRenamed*` do the same too?
I.e. why that second function was introduced in the first place?
Shouldn't this PR just remove all `withPriority` stuff and always propagate the priority?
|
@oxij Thanks for doing a review of this. You bring up some good questions. Let me try to answer them.
Originally, the documentation for the functions in question mentioned that they don't copy the priority. I assumed it wasn't a bug, but intentional. In the few previous PRs I sent surrounding this issue, no one seemed to think it was a bug. This PR changes My assumption is that this isn't really "fixing a bug", but adding an additional feature to these functions. I think that most people who use
Yes, this PR changes
It makes sense to have
Yeah, that is one option. I'd be fine with that (since it would make the code slightly simpler), but I'm not sure why This PR does change that functionality, but at least it provides a backdoor for someone to use who is depending on that functionality (by leaving the option available in |
I see. I guess it would be nice to hear what @nbp thinks about this then. I see no explanation for not propagating the priority in the first place. |
I think this is fine, this change makes sense, and I also even doubt anybody relied on the previous behavior |
This commit changes the
mkAliasOptionModule
function to make sure that the priority for the aliased option is propagated to the non-aliased option.This also affects the
mkRenamedOptionModule
function in a similar fashion.This also removes the
mkAliasOptionModuleWithPriority
function, since its functionality is now subsumed bymkAliasOptionModule
.This change was recommended by @nbp to see what would be the effect of doing this:
#53397 (comment)
Motivation for this change
The motivation for this change (as well as a use-case) is listed in #53397 (comment).
Pinging @nbp, since he suggested this change. Also pinging @infinisil since he helped with the original PR that inspired this change.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)