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.

Sign up for GitHub

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

Jump to bottom

Set shorthandOnlyDefinesConfig = false; in hm-config #2305

Open
DrRuhe opened this issue Sep 24, 2024 · 3 comments · May be fixed by #2307
Open

Set shorthandOnlyDefinesConfig = false; in hm-config #2305

DrRuhe opened this issue Sep 24, 2024 · 3 comments · May be fixed by #2307
Labels
bug Something isn't working

Comments

@DrRuhe
Copy link

DrRuhe commented Sep 24, 2024

Description

The home manager module defines the nixvim module with shorthandOnlyDefinesConfig = true;. This means when trying to import a config module, one gets an error unless they make the nixvim config module into a function
https://github.com/nix-community/nixvim/blob/main/wrappers/hm.nix#L24

Minimal, Reproducible Example (MRE)

# as a home-manager module
programs.nixvim = {
  imports = [
    ./nixvim-config.nix 
  ]
}

Causes the error error: The option home-manager.users.username.programs.nixvim.imports' does not exist.`

To fix it, one has to declare the home manager to not be "shorthand", which gets rid of the error:

# as a home-manager module
programs.nixvim = {...}:{
  imports = [
    ./nixvim-config.nix 
  ]
}

The Fix

Set shorthandOnlyDefinesConfig = false;. I dont see nixvim using a config option, so this should not break anything.

My Usecase

I want to expose nixvim as a package of my config flake as well as be part of the home manager config. Therefore I have one single config that defines the nixvim options which is then imported in my home-manager config and exposed as a package via inputs'.nixvim.legacyPackages.makeNixvim
@DrRuhe DrRuhe added the bug Something isn't working label Sep 24, 2024
@MattSturgeon
Copy link
Member

Wouldn't this prevent someone defining nixvim options as follows:

programs.nixvim = {
  foo = "bar";
  bar = "baz";
};

And they'd instead need to do:

programs.nixvim = {
  config.foo = "bar";
  config.bar = "baz";
};

Or have I misinterpreted the purpose of shorthandOnlyDefinesConfig?

Also, I plan to replace the submoduleWith with (evalNixvim {}).type1, are you aware of how that'd fit in with this?

Footnotes

  1. evalNixvim is a thin-wrapper for lib.evalModules ↩

@MattSturgeon
Copy link
Member

MattSturgeon commented Sep 24, 2024 •
edited
Loading

Ok, re-reading the docs:

Enabling this only has a benefit when the submodule defines an option named config or options. In such a case it would allow the option to be set with the-submodule.config = "value" instead of requiring the-submodule.config.config = "value".

You're right, this option only has an effect when the submodule has a config or options sub-option. Historically (before #1324) we used to have an options option, so that is likely the original reason why we set shorthandOnlyDefinesConfig.

It won't be set when using (lib.evalModules {}).type, so I'll likely bundle the fix for this into the PR switching away from submoduleWith.

@MattSturgeon MattSturgeon linked a pull request Sep 24, 2024 that will close this issue
Open
@DrRuhe
Copy link
Author

DrRuhe commented Sep 24, 2024

Alright, thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

wrappers: use (evalModules {}).type for nixvim submodule MattSturgeon/nixvim
2 participants
@MattSturgeon @DrRuhe