Is it possible for configuration changes to reflect in nixCats without rebuilding?

[meetmangukiya]

The first main feature is the nixCats messaging system, which means you will not need to write ANY lua within your nix files (although you still can), and thus can use all the neovim tools like neodev that make configuring it so wonderful when configuring in your normal ~/.config/nvim

I initially thought it was possible for me to just tell nixCats the config dir in my config repo and it will create a wrapped nvim that will load lua code from the specified directory instead of the standard ~/.config/nvim. But it looks like at the rebuild/switch it copies all the files in the luaPath over to the nix store and link that way, which means I have to build again for the config changes to reflect in the wrapped neovim? I naively tried to replace the cp -r ${luaPath}/* $out/ with ln -s ${luaPath} $out/ but that didn't really work(probably because nix wants to know definite hashes of the directories?).

In summary, is it possible to have live loading of lua code without having to rebuild nixcats if there is no nix change?

[BirdeeHub]

nixCats-nvim/flake.nix

Line 339 in cd8e419

wrapRc = false;

:h nixCats.flake.outputs.settings

^ documentation

Yes, with wrapRc option. Obviously if you change any nix code you will still have to rebuild.

The quick tip in the help I linked is how I use the option. Basically, I just launch the version with wrapRc = false when im messing around with lua, and then rebuild when im done and go back to using the one with wrapRc = true so that it imports properly on other machines again. (The option just skips copying the directory and then you symlink it yourself)

Its really good for messing around with lua but because it doesnt copy it to the store it obviously wont be included if you do nix run yourconfiglink on another machine, hence why you would want 2 otherwise identical outputs, one with wrapRc = true and the other with wrapRc = false. Personally I have the wrapRc = true one aliased to vi and the wrapRc = false aliased to vim. That way I can use vi . normally, and when I want to mess with lua I can use vim . and see my changes reflected, and then rebuild and go back to using vi .

This has the added benefit that vi . is frozen how it was, meaning if I mess it up completely when messing with my lua in the vim . version I can open up vi . and fix it with a working neovim config rather than reverting all of what I just did just to be able to open the editor.

[bartbie]

Obviously if you change any nix code you will still have to rebuild.

YMMV but direnv should watch the nix files and rerun the shell on changes

[BirdeeHub]

you could yeah, it still takes a while to rebuild when its integrated into your whole system config so for best experience editing, not having to rebuild on lua changes is very nice.

[bartbie]

Oh yeah I don't disagree, I was thinking about using it along the wrapRC trick to get it both.

BTW, how can I change the config nixCats's nvim uses? I've tried to apply a hack I thought of recently - overriding neovim package with customRC option to source specific dir I want (in this case it's CWD since i use it for my dev shell) - however I couldn't make it work in nixCats. I tried providing custom unwrapped pkg like so but it doesn't seem to work lol

packageDefinitions.nvim-dev = {pkgs, ...}: {
  settings = { wrapRc = false; ...};
  neovim-unwrapped = pkgs.neovim.override {
   configure.customRC = ''
     source $SOMEVIMRC
   '';
  };
  ...
}

[BirdeeHub]

so, with wrapRc true, the path used is the path in the luaPath variable at the top of your template, which must be a store path (either a directory in your nix config, or from a flake input or something)

with wrapRc false it uses either ~/.config/nvim OR ~/.config/<configDirName setting> OR unwrappedCfgPath depending on your settings in packageDefinitions for that package. see :h nixCats.flake.outputs.settings for all options and their default values. unwrappedCfgPath can be any path, although absolute paths are recommended obviously.

And remember, you can make as many packages as you want, making a second entry in packageDefinitions with the same categories and settings except wrapRc = false for experimenting with your lua is encouraged and very useful. However wrapRc = false will not import the config with the package because its not in the store, so you should have at least 1 package with wrapRc = true for running from anywhere via nix run

[BirdeeHub]

Also, about your "hack"

You can import an already configured nixCats based config and RE configure parts of it, and if you want to do that, you can still source new directories.

On the first configure you should use luaPath variable and the unwrappedCfgDir setting but when you RE configure it, you are using the original luaPath, so you may want to import a second directory for the extra config, and how to do that is demonstrated in that template, along with some other cool tricks.

Although that new second directory won't be affected by wrapRc setting and would always be loaded, so you wouldn't want to do it on the main configuration.

The template in the link isnt for beginner users, but for advanced users it shows some cool stuff you can do if you wanted to, say, import your nixcats config in a dev shell, make a modification, and then include it in the shell.

[BirdeeHub]

An aside because I think you also mentioned another thing

If your Lua config is in a separate repo you can still put it in there you just have to import the repo. Just put it in flake inputs and put the input in the LuaPath variable. You could even do sub paths of said other repo with "${inputs.theinput}/some/subpath".

However this wouldn't solve the live update thing, because that particular version of said other repo is now in the store, so you would still need to use the wrapRc option or rebuild.

LuaPath option can only accept store paths, this is a hard limit of derivations. Derivations are built in a sandbox that doesn't have access to the rest of the filesystem (or the internet, although you can supposedly do some magic with fixed output derivations to get internet, you just have to specify the resulting hash of the final output of the derivation, and it will fail if it doesn't match. Pretty sure this is how they do some of the npm stuff. Normally the hash is of the derivation instructions but for fixed output ones, the hash is of the result.)