is it possible to just overrideAttrs the wrapRc option?

[rafaeljacov]

so instead of just creating a copy of one of the existing packageDefinitions and setting wrapRc = false; we can just override it

[BirdeeHub]

.override or .overrideNixCats is preferable to .overrideAttrs, you can use prev.packageDefinitions.whicheverpackage and change values from it. It is a defined interface of nixCats.

https://nixcats.org/nixCats_overriding.html#nixCats.overriding.packageDefinitions

Merge functions exist to help you deal with merging nested function results together to make this nicer, documented in the overriding help as well.

In addition, every package exports a module, which does a similar thing to override based on an existing package, if you would prefer to use that, but then you have to have some way to eval modules (nixos, home manager, nix darwin), which can be hard to do in dev shells (would require calling lib.evalModules)

.overrideAttrs can be used as well, but it is more limited and only is guaranteed to work well when overriding the passthru values (which will actually update the resulting package as you might expect), as theoretically you could accidentally remove stuff you kinda needed, and it may not play well with using override after it if you use overrideAttrs to change other values than the designated passthru values. More footguns there and you shouldn't need to use it over using .override or .overrideNixCats. I do hope one day to iron out the last of the issues with the interaction between .override and .overrideAttrs, but it is uhhh, well its not exactly the easiest problem but should be fixable mostly from within this function someday via some blatant exploitation of functional programming but fixed points are hard so, I am unsure how exactly to proceed with that for the time being, and the existing options for overriding are already plenty without overrideAttrs, and due to the .overrideNixCats alias, will be useable even if you shadowed .override on accident by using callPackage higher up in the call stack

---

If you wanted to do it within your base config, without using .override, just factor it out

packageDefinitions = let
  birdeevim_settings = { pkgs, name, ... }: {
    # ...
  };
  birdeevim_categories = { pkgs, name, ... }: {
    # ...
  };
  birdeevim_extra = { pkgs, name, ... }: {
    # ...
  };
in {
  birdeevim = args: {
    settings =  birdeevim_settings args // {
      wrapRc = true;
      aliases = [ "vi" "nvim" ];
    };
    categories =  birdeevim_categories args // {
    };
    extra = birdeevim_extra args // {
    };
  };
  # ... other package definitions, which can use the base stuff you factored out, or not. ...
};

So, yeah, when importing it somewhere else, you can override, within your base config, you can factor it out.

What you choose to make a separate package in your base config for, and which to use .override for is up to you.

---

Also if all you cared about was wrapRc, it actually lets you set it to a string, and you can set that as an env var to unwrap it, for a toggle mechanism if desired.

https://nixcats.org/nixCats_format.html#nixCats.flake.outputs.settings

---

Hopefully at least one of those 3 answers answers the actual question haha (the first one probably had too much detail, but it boils down to prefer .override and .overrideNixCats to .overrideAttrs, and some links to help, and 2 deep dive source links if you are curious)