Is the nix function mkOutOfStoreSymlink still relevant when using nixCats?

[mettavi]

Hi, I recently installed nixCats and it is working well so far.

I have one question though about the following nix config that I was using:

    xdg.configFile = {
      # link without copying to nix store (manage externally) - must use absolute paths
      # mkOutOfStoreSymlink is required to allow the lazy-lock.json file to be writable
      "nvim".source =
        mkOutOfStoreSymlink "${config.home.homeDirectory}/${nix_repo}/home/shared/dots/nvim";
    };

This function allows nix to manage config files without copying them to the nix store. They are loaded directly from the local file system in the git repo. This is useful for apps which write directly to the config files. In this case, lazy.nvim tries to write to lazy-lock.json but it cannot if the file is linked to the nix store. That's why I used mkOutOfStoreSymlink to prevent this problem.

But does nixCats still work with this settings, or does it copy the neovim lua configuration to the nix store regardless? If so, then I guess I should just link the lua config to my home directory with the regular home.file setting?...

I am not currently seeing any errors with lazy.nvim being able to write to lazy-lock.json, but I just wanted to make sure that the mkOutOfStoreSymlink config makes sense when using nixCats, and if not, whether home.file will work ok in its place.

Many thanks for any clarification!

[BirdeeHub]

No, setting unwrappedCfgDir to point somewhere is basically the same thing.

mkOutOfStoreSymlink writes only a symlink to an out of store file into the store

nixCats loads your configuration, and you can write any path into the store for it to load, inside or outside of the store. No need to point it at an in-store symlink to somewhere out of the store, you can just point it there flat-out.

However the luaPath value accepts only store paths, there is an unwrappedCfgPath setting for out of store paths, which you can swap between via nix, or define a variable to define to use to swap between them (see :h nixCats.flake.outputs.settings)

wrapRc setting allows you to swap between store and out of store directories for your config. You can set it true or false per package, or you can set it to a string, which if you define as an environment variable, will set wrapRc to false for that invocation of nvim. i.e. wrapRc = "MY_VAR" would mean that usually it points to the store one, and then export MY_VAR=anything will cause it to point at unwrappedCfgPath instead.

In short, you dont need to do that, and you can achieve the same stuff with unwrappedCfgPath and wrapRc settings, per package. This, way, you have access to this ability if you are using home manager or not.

What mkOutOfStoreSymlink would allow you to do, would be to luaPath = mkOutOfStoreSymlink "${config.home.homeDirectory}/${nix_repo}/home/shared/dots/nvim";, but this is totally unnecessary. luaPath only accepts store paths, and a symlink generated in this way is a store path, so it would work. But there is already unwrappedCfgPath and wrapRc settings for this purpose and they don't rely on home manager to function, so you should provide a default path to use from the store like ./. or ./nvim or something for luaPath, and override it per package with unwrappedCfgPath (or even wrappedCfgPath)

The whole idea being that it launches stuff EXACTLY the same way regardless of where the config is, making it easy to "unwrap" the config, test lua changes, and then "wrap" it again and have it work exactly the same but now properly bundled again.

[BirdeeHub]

The issue with the lazy lock file, honestly, you should just set in your lua config a path it should write to.

It cant write to the store. Your config is in the store. If you put a different path in your lua outside of the store, say, the path to where you normally keep your config, it will look there instead.

The templates which use lazy.nvim tell you to point it to nixCats.settings.unwrappedCfgPath regardless of if your config is wrapped or not for this reason. They have some extra error handling there too that is not strictly necessary but makes it less likely for people to get errors when messing around with the template at first. You can set it wherever you want, and you can pass any info from nix via the nixCats global provided to your config, store paths, regular strings, anything other than nix functions can be translated to lua and placed into there.

[mettavi]

so you should provide a default path to use from the store like ./. or ./nvim or something for luaPath, and override it per package with unwrappedCfgPath (or even wrappedCfgPath)

Thank you so much for your detailed reply, it is a big help and I feel I understand it better now. But just to make sure, I want to check the following:

Firstly:
I was thinking that neovim would continue to look for its config at ~/.config/nvim/, but now I understand that nixCats itself manages the location and loading of the lua config...and I have my lua config inside my git repo, so I don't need to link it to ~/.config/nvim (except perhaps for my lazy-lock.json)...

Correct?

Secondly:
Currently, for my default in nixCats I have luaPath set like this:

luaPath = ../../../dots/nvim;

I have a main nvim package defined in nixCats with wrapRc = true;

Then, I have defined a second package in nixCats "testnvim", where I have set:

wrapRc = false;
unwrappedCfgPath = utils.mkLuaInline "os.getenv('HOME') .. '/.nix-config/home/shared/dots/nvim'";
configDirName = "nixCats-nvim";

So in the case of the main nvim package, nixCats is copying the lua config directory to the nix store and loading it from there...

And in the case of the testnvim package, nixCats is reading the lua config directory directly from the location in the git repo, without copying it to the nix store...

Correct?

Many thanks once again for your kind assistance and for making nixCats available! 🙏

[BirdeeHub]

So in the case of the main nvim package, nixCats is copying the lua config directory to the nix store and loading it from there...

And in the case of the testnvim package, nixCats is reading the lua config directory directly from the location in the git repo, without copying it to the nix store...

Yep!

Exactly correct.

luaPath = ../../../dots/nvim;

This accepts only store paths. paths like ../../../dots/nvim are copied to the store (assuming they are within your nix config)

This is done by nix, nixCats simply checks that it is a store path first for that option.

wrapRc = false;
unwrappedCfgPath = utils.mkLuaInline "os.getenv('HOME') .. '/.nix-config/home/shared/dots/nvim'";

wrapRc = false means, DONT use luaPath for this package and use unwrappedCfgPath instead.
unwrappedCfgPath is not checked, it can be just a string.
in this case, you have used mkLuaInline to cause it to not be escaped either and place the value literally instead, allowing you to execute lua code there.

If you did not use mkLuaInline, it would have been placed into a [[string]] (or a [=[string]=] or a [==[string]==], etc... yes that is how it escapes it, people forget lua has these) and the os.getenv('HOME') .. would not execute. But you did, so this works.

It uses the exact same code to load the path, regardless of if it was provided by luaPath or unwrappedCfgPath.

configDirName = "nixCats-nvim";

This just sets $NVIM_APPNAME

If you have wrapRc = false and do NOT have unwrappedCfgPath set, it will look in ~/config/$NVIM_APPNAME

But usually you will want unwrappedCfgPath set. But it is useful still because:

Folders like vim.fn.stdpath('data') are also controlled by this variable. Usually it is fine to have all your packages with the same NVIM_APPNAME because everything is being installed via nix anyway, but sometimes you might want 2 different ones, even just for debugging sometimes.

I actually prefer all my packages to have the same NVIM_APPNAME because my AI auths live in vim.fn.stdpath('cache') and places like that so if they all share the same NVIM_APPNAME, all the packages with my AI plugins installed see the same ones, no need to log in for each one.

[BirdeeHub]

The only notable difference between how nixCats loads the config folder, and how it is normally loaded is:

It does not override the path returned by vim.fn.stdpath('config')

The reason for this is documented at the top of the page here https://nixcats.org/nixCats_format.html

But in a nutshell that is because usually stuff only goes to that path to write to it. If I overrode it, all that stuff would fail because it would try to write to the store.

This includes the lazy lock file. You can set it to a better location if you wish, such as nixCats.settings.unwrappedCfgPath but at the very least, it will not cause a failure if you don't change it as it will write to vim.fn.stdpath('config') which nixCats doesnt change.

Outside of that 1 difference, there should be no difference in how a normal config directory is loaded, and how the nixCats-provided config directory is loaded. I worked very hard to accurately recreate the process outside of that 1 detail which was intentionally left unchanged.

If you were curious how that actually works, the code that loads the init.lua is here which you can view at runtime with vim.cmd.edit(nixCats.nixCatsPath .. "/lua/nixCats.lua") and gets ran by setting VIMINIT to lua nixCats.init_main() and the code which adds the config directory to the runtime path is here which gets ran via the wrapper before neovim does literally anything else using the --cmd argument.

The info in the above paragraph is not necessary to fully understand to be clear, but if you were curious, that is where to go. Definitely check out vim.cmd.edit(nixCats.nixCatsPath .. "/lua/nixCats.lua") tho cause that should be enlightening, thats where basically all of the nix-provided information ends up. And you can check out the wrapper and the only other setup file in the derivation if you want too obv.

nixCats is just a good useage of pkgs.makeWrapper or pkgs.makeBinaryWrapper lol.

If you havent used those, they are really powerful, A+ shell scripts. But there's a lot to do to wrap neovim properly lol

[mettavi]

Thanks so much again @BirdeeHub! I have three more "concept checking" questions, just to check my understanding:

configDirName = "nixCats-nvim";

This just sets $NVIM_APPNAME
If you have wrapRc = false and do NOT have unwrappedCfgPath set, it will look in ~/config/$NVIM_APPNAME

Hmm, so what is the effect of having BOTH unwrappedCfgPath and configDirName set like this? -->

wrapRc = false;
unwrappedCfgPath = utils.mkLuaInline "os.getenv('HOME') .. '/.nix-config/home/shared/dots/nvim'";
configDirName = "nixCats-nvim";

In this case, does unwrappedCfgPath override configDirName, or does the latter get appended to the former, so the resulting config path is ~/.nix-config/home/shared/dots/nvim/nixCats-nvim?

Usually it is fine to have all your packages with the same NVIM_APPNAME because everything is being installed via nix anyway, but sometimes you might want 2 different ones, even just for debugging sometimes.

So configDirName/$NVIM_APPNAME is basically the folders that are loaded, not the package names (which are set by packageNames = [ "nvim" ... ];), yes?

One final question, this might be super obvious, but please humour me...

One of the advantages of mkOutOfStoreSymlink was that you could change your neovim lua config and then immediately load the new config without having to do a nixos-rebuild/darwin-rebuild switch. unwrappedCfgPath, has the same advantage, right?

PS I think nixCats is awesome! 👍

[BirdeeHub]

unwrappedCfgPath overrides configDirName

unwrappedCfgPath, has the same advantage, right? Yes

https://neovim.io/doc/user/starting.html#%24NVIM_APPNAME, except unwrappedCfgPath wins