Is there a way to reuse a home-manager config of nixvim as a standalone one?

[charludo]

Basically the title.

I have been using nixvim for some time now, and would like to expose my home-manager based config of it as a standalone package.

I would also consider turning my hm config into a standalone config, and then reusing the result in home-manager. From what I gather, that's the suggested method in the docs.

However, in my case I have the complicating factor that I've defined custom options whose config values affect the nixvim configuration (things like a top-level palette option, and a per-language toggle which enables/disables complete lsp/formatting/linting/... setups for individual languages.

I'm unable to get either way to work:

• if I leave my config as-is, the hm install works, but in the standalone one, programs.nixvim is undefined, and I have not found a way around this which properly evaluates all of the nixvim config before "lifting" programs.nixvim.* to *;
• if I turn the hm config into a standalone one, I can expose a package with my complete config, but now home-manager complains that all of nixvim's options do not exist, and I have in turn not found a way to make them available under programs.nixvim.

I am sorry if this doesn't make too much sense. My config lives here. If someone can point me in the right direction or has done something similar, I'd be very grateful to hear it!

[MattSturgeon]

There are several ways to approach this, but I'll start by mentioning it is easier to reuse standalone nixvim modules in home-manager than use modules from home-manager in a standalone nixvim.

---

The first thing to undeststand is a high-level concept relating to the module system itself: how submodules work.

TL;DR: submodules are not special, they are just a normal module configuration (aka module eval) nested within another module configuration.

More specifically, an option of submodule type expects its definition values to be modules, then the submodule type merges those modules (using lib.evalModules) and uses the final conflagration's config as the option's final/merged value.

This means a submodule can contain arbitrary modules; with option declarations, imports, config definitions, default values, etc.

---

This is relevant here, because programs.nixvim is a submodule. More specifically, it is a submodule that expects Nixvim modules and evaluates to a nixvim configuration.

That's why everything within programs.nixvim is the same as what you see in a standalone nixvim configuration.

---

Ok, enough theory. What does that mean in practice?

Well, one approach for reusing nixvim configuration is to reuse the resulting package. I.e. include your standalone nixvim package in your home.packages.

This can be extended using the .extend function on the package.

Another approach is to define your nixvim modules in a shared location, and import them into both your standalone nixvim configuration, and home-manager's programs.nixvim submodule:

# home-manager
{
  programs.nixvim = {
   imports = [ ../nixvim/modules ];
  };
}

If you're working with nixvimConfigurations (instead of directly with the resulting packages), as shown in the "experimental" flake-parts templates, then you can also use .extendModules on a nixvimConfiguration, similar to .extend on an classic nixvim package.

---

If you really wanted to define all your nixvim modules in home-manager configuration and then reuse them elsewhere, this is possible, but convoluted. It also isn't very idiomatic. Without NixOS/nixpkgs#391544, it's even more convoluted...

Because we don't have NixOS/nixpkgs#391544, we can't access metadata about the submodule's configuration; we only have its final config value, which is used as the programs.nixvim option value. The best workaround for now would be to declare an option within the submodule and use it to pass relevant metadata out of the submodule.

I won't spend time creating an example, because I think it's a bad way to approach the problem. My recommendation would be to write re-usable nixvim modules as much as possible, then import these into all your nixvim configurations (standalone or submodule).

---

As an aside, our documentation on this is probably not aligned very well with what I wrote here. I suspect we're still pushing the "use a nixvim package and extend it" strategy as the main/only solution. Help improving the docs is always appreciated!

Relevant docs are currently Installation -> Standalone usage and Nixvim Platforms -> Standalone.

[charludo]

Wow, I did not expect such a thorough answer! Thank you for the effort you put into this!!

Another approach is to define your nixvim modules in a shared location, and import them into both your standalone nixvim configuration, and home-manager's programs.nixvim submodule:

# home-manager
{
  programs.nixvim = {
   imports = [ ../nixvim/modules ];
  };
}

... oh my god. I feel stupid. Let's just say, this is much, much simpler than the unholy concoction of evalModules and mergeAttrs I had goign on in my frankenstein-ian attempt.

I won't spend time creating an example, because I think it's a bad way to approach the problem. My recommendation would be to write re-usable nixvim modules as much as possible, then import these into all your nixvim configurations (standalone or submodule).

Yes, good point. I went with your recommendation, and now it's working flawlessly. I have a nixvim module which simply gets imported by both the package and the hm config.

Seriously, thank you for your help.

For anyone stumbling upon this in the future looking to do the same, I'll leave my solution here:

• nixvim module
• package declaration
• home-manager config