Migrating nixCats to nix-wrapper-modules; how to emulate nested categories.

[bbaserdem]

I'm in the process of migrating my nixCats configuration to nix-wrapper-modules. I'm hitting a bit of a snag trying to replicate my workflow.

One thing I am running into is; I was using the nested categories feature of nixCats. A quick example would be the following startupPlugins block for the category definitions;

startupPlugins = with pkgs.vimPlugins; {
    # Main plugins to have
    system = [
      lze # Lazy loader for plugins (NEEDED)
      lzextras # Lazy loader extras
      nvim-lspconfig
    ];

    tools = {
      files = [
        oil-nvim # File browser
        oil-git-status-nvim
      ];
      formatting = [
        myVimspell
      ];
    };

    ui = {
      theme = [
        nvim-web-devicons
      ];
      views = [
        snacks-nvim
      ];
    };

    languages = {
      latex = [
        vimtex # LaTeX suite, can't be lazy loaded
      ];
    };
};

I would then, for different exports, could enable and disable the base class (I would turn off all the categories besides the system for a bare packaged nixCats instance with no plugins, have an instance of nixCats with only latex dependencies in my devshell for writing my thesis etc.)

I'm trying to emulate this, but I'm a bit stuck with nix-wrapper-modules nvim module. I was trying to this; thinking a spec could be a set with the data field as a list of plugins; but this is not working

      config.specs.tools = {
        lazy = true;
        data = [
          {
            # AI tools
            name = "ai";
            data = with pkgs.vimPlugins; [
              claudecode-nvim
              claude-fzf-nvim
              fzf-lua
              sidekick-nvim
              agentic-nvim
            ];
          }
        ];
      };

My understanding is, this sort of nested category approach doesn't work with specs. I've been reading the documentation, but coming up blank on how to accomplish this.

(A second question I have is, I want to have one module, and have two instances of neovim on my system. One with all the plugins etc. that will be called with nvim, and one with only the system plugins that will be called with vim. I'm unsure how to use one module, but package multiple packages with some options changed in that module.)

I don't see other discussions related to this move from nixcats to nix-wrapper-modules, other than an example so hope I'm not asking redundant questions.

[BirdeeHub]

Unfortunately, it is not quite as 1 to 1 as that, as the internal lists of specs do not accept lists themselves, only the top level ones accept lists.

There are several reasons why it works this way, but it basically boils down to, this is the module system, and this was the most flexible I could find.

I was not as worried about having it arbitrarily nest when one can make their own options, and instead focused on how usable it was with the module system.

When it starts getting arbitrarily nested where anything could be a list or a set, it starts to get hard to override without making options for it.

However, you have the whole module system to work with now, and those specs accept function form submodules, should you need that.

Im pretty sure that either by passing a function-type submodule to a spec, or modifying the base definition of all of them to include more options using specMods (and maybe specMaps which is capable of filtering items but is definitely not an option for the faint of heart), you can find some way of sub-categorization that makes you happy! They do all have enable fields, which will at least make them easy to toggle!

If I think of a nice one myself that doesn't involve reinventing the category system from nixCats with module options (which, one could do if they really wanted), I will be sure to put it here.

Maybe something like this?

  config.specs.images = { config, ... }: {
    options = {
      subcategories = lib.mkOption {
        # ???
      };
    };
    config = {
      lazy = true;
      data = [
        {
          enable = config.subcategories.???;
          data = pkgs.vimPlugins.image-nvim;
        }
      ];
      postpkgs = with pkgs; [ # <- you probably named yours extraPackages, I put a pre and a post in my config
        imagemagick
        ueberzugpp
      ];
    };
  };

Then to override it from a later call to .wrap or another module you import, you could

config.specs.images = { ... }: {
  subcategories = ???;
};

or

config.specs.images.subcategories = ???;
config.specs.images.data = wlib.ignoreSpecField; # <- unfortunately you have to make it a valid spec still

---

As far as being able to install multiple nvim packages to home.packages or environment.systemPackages without collision errors, like you are used to being able to do in nixCats, this is still possible.

For that, you would change config.binName to be something else, and then set config.settings.dont_link = true

You will also want to make sure your aliases from settings.aliases do not conflict.

Then, they will be able to be installed simultaneously without collision errors.

You can see in my nvim module I made myself some options for that on top of the existing ones

https://github.com/BirdeeHub/birdeevim/blob/43c39c5fe16bbf745ac8aaadf3a1a0574e27b602/nix/default.nix

and then in its flake I can set those options again to make multiple packages to export

https://github.com/BirdeeHub/birdeevim/blob/43c39c5fe16bbf745ac8aaadf3a1a0574e27b602/flake.nix#L178-L185

Also, in my config, where I use mine as home manager modules, you can do this to achieve similar

I imported the module using mkInstallModule and then I can do

  wrappers = {
    neovim.enable = true;
    # neovim.someotheroption = idk;
  };
  home.packages = with pkgs; [
    # I also want a second one, same stuff as I had, but test_mode = true (I made the test mode option in my config, it sets binName and settings.dont_link)
    (config.wrappers.neovim.wrap { settings.test_mode = true; })
  ];

But really, any way you can get a package, or evaluate a module, or simply have access to an importable module, you can make a variation of your config, by either importing the module along with more modules, or calling .wrap .apply or .eval (which are exported from the top level on the package via passthru, and in the modules as a read-only option)

---

As far as other discussions on this topic, while the exact thing you are asking for has not been mentioned, there have been some other discussions on the neovim module, #254 and #188 which may have useful info for inspiration either now or eventually

Also semi-related, the specs really are quite flexible.

I made mine accept other wrapper modules

https://github.com/BirdeeHub/birdeevim/blob/43c39c5fe16bbf745ac8aaadf3a1a0574e27b602/nix/general.nix#L171-L196

which I achieved using only the specMods setting

https://github.com/BirdeeHub/birdeevim/blob/43c39c5fe16bbf745ac8aaadf3a1a0574e27b602/nix/nvim-lib.nix#L35-L89

[bbaserdem]

Thank you, I'll definitely showcase my setup once I'm at a happy place. And I don't mind changing my workflow around the current capabilities; I find myself not really using the many categories I defined anyway; so it was more of an organizational scheme.

Lot to learn with nix-wrapper-modules still, i didn't realize a spec could be a module; this does open new capabilities for me.

The current solution I'm converging on is just to use specs with naming <category>-<subcategory>

[BirdeeHub]

I find myself not really using the many categories I defined anyway; so it was more of an organizational scheme.

Same to be honest. I still wanted some of that, but I decided not to focus as hard on that, because the more nested it became, the less useful it became anyway. This felt like it was enough.

[bbaserdem]

A quick question @BirdeeHub ; can you think of a quick way to disable all specs except one? I currently disable them by hand for a seperate package like this; (this is a flake-parts module)

# Package definitions
{inputs, ...}: {
  flake = {

    # Custom neovim packages
    perSystem = {
      config,
      pkgs,
      ...
    }: {
      packages = {
        # Different packages with configs

        # The bare neovim package
        neovim-bare = config.packages.neovim.wrap {
            # Use neovim from nixpkgs
            package = pkgs.neovim;
            # Replace system nvim command
            settings = {
              dont_link = true;
              aliases = [
                "nx-none"
              ];
            };
            binName = "vim";
            # Disable all specs
            specs = {
              system.enable = true;
              ui.enable = false;
              # ...
            };
          };
        };
      };
    };
  };
}

But it becomes cumbersome, and not robust if I want to add future specs. I assume there is a specMaps function I can write, but I'm blanking on how to write that function. I think also the config.extraPackages = config.specCollect (acc: v: acc ++ (v.extraPackages or [])) []; collector needs to be modified to check for spec enable status; but again not super sure on how to do this; my nix skills are failing me a bit.

EDIT: This doesn't seem to work, I'm getting A definition for option flake.wrappers.neovim.specs.system.data' is not of type null or str|path|drv or list of spec with main field: data of (null or str|path|drv)'. which i assume means that the wrapped packages' specs attrset is completely getting written over. Is there a way to do this properly?

ALso would setting settings.block_normal_config false be enough to make neovim just use the config in the regular ~/.config/nvim directory? Or do I need to set further options for it?

[BirdeeHub]

https://github.com/BirdeeHub/birdeevim/blob/fbf66545946260adf5f26d157aa429b3a8584fcb/nix/default.nix#L68-L77

^ Disabling all but 1, I have a minimal option, it disables all of them, except the ones I explicitly enable

  config.specMods = lib.mkIf config.settings.minimal (
    { parentSpec, ... }:
    {
      config.enable = lib.mkOverride 1400 (parentSpec.enable or false); # 1400 is 100 higher than mkOptionDefault (1500)
    }
  );

And then I just have it be explicit about the ones I still want.

  config.specs.general = {
    enable = lib.mkIf config.settings.minimal (lib.mkDefault true);
    # ...

---

As far as overriding it after the initial definition:

EDIT: This doesn't seem to work, I'm getting A definition for option flake.wrappers.neovim.specs.system.data' is not of type null or str|path|drv or list of spec with main field: data of (null or str|path|drv)'. which i assume means that the wrapped packages' specs attrset is completely getting written over. Is there a way to do this properly?

https://birdeehub.github.io/nix-wrapper-modules/lib/wlib.html#function-library-wlib.ignoreSpecField

^ you are most likely running afoul of this... config.specs.python = { ... }: { enable = false; };

---

Also would setting settings.block_normal_config false be enough to make neovim just use the config in the regular ~/.config/nvim directory? Or do I need to set further options for it?

block_normal_config will make it leave the ~/.config/nvim on your rtp, rather than removing it. But it will not source the init.lua from it, because it sets VIMINIT.

You likely do not want to set it to false.

If you want to source the normal location, you should set

settings.config_directory = lib.generators.mkLuaInline "vim.fn.stdpath('config')";

(which is the default, actually)

---

config.extraPackages = config.specCollect (acc: v: acc ++ (v.extraPackages or [])) [];

If it was not enabled, this should not get that value.

specCollect folds over the final list of specs. They have already been filtered based on their value of enable. And also after being sorted into their final order

When using specCollect, you will receive only specs where enable was true.

specMaps happens before the enable filter (and the sort)

If something is being added to the PATH unexpectedly, it might be coming from the runtimeDeps field on the plugin from nixpkgs?

By default we collect those.

https://github.com/BirdeeHub/nix-wrapper-modules/blob/main/wrapperModules%2Fn%2Fneovim%2Fdefault-config.nix#L37-L48