Weird mkOutOfStore symlink recursion

Hi folks,

I’m currently setting up nvim on my nixos config (for the 3rd time).
I started with something as simple as this:

xdg.configFile."nvim".source = config.lib.file.mkOutOfStoreSymlink "${config.home.homeDirectory}/nix-config/home/programs/astronvim/template";  

Which worked well enough.
Then i migrated to nixvim, but so far i find it very annoying that i have to rebuild everytime i make a change, and it’s currently very laggy for some reason, which is annoying to debug because of the rebuild times.
I’ve looked into nixcats, but it looks like it offers much more than i want, and honestly, seems way too complicated for my tiny brain.
So I’m trying to set it up again using the mkOutOfStoreSymlink solution, as that allowed me to have a quick feedback loop when modifying my config, and replacing mason with https://github.com/dundalek/lazy-lsp.nvim

I’m encountering the following issue right now though, i want to keep using stylix.
When using stylix and symlinking this issue occurs:
https://github.com/nix-community/home-manager/issues/5175#issuecomment-2858394830

So i just disabled stylix for neovim and it works, but i still want to have theming, so i just put it inside of my nvim/default.nix to generate the base16-nvim palette using that (basically what stylix does behind the scenes)

home.file.".config/nvim/init.lua".text = ''  
... requires and other stuff ...

-- Auto-generated base16 colorscheme from Nix

require('mini.base16').setup({

palette = {

base00 = "#${config.lib.stylix.colors.base00}",

base01 = "#${config.lib.stylix.colors.base01}",

base02 = "#${config.lib.stylix.colors.base02}",

base03 = "#${config.lib.stylix.colors.base03}",

base04 = "#${config.lib.stylix.colors.base04}",

base05 = "#${config.lib.stylix.colors.base05}",

base06 = "#${config.lib.stylix.colors.base06}",

base07 = "#${config.lib.stylix.colors.base07}",

base08 = "#${config.lib.stylix.colors.base08}",

base09 = "#${config.lib.stylix.colors.base09}",

base0A = "#${config.lib.stylix.colors.base0A}",

base0B = "#${config.lib.stylix.colors.base0B}",

base0C = "#${config.lib.stylix.colors.base0C}",

base0D = "#${config.lib.stylix.colors.base0D}",

base0E = "#${config.lib.stylix.colors.base0E}",

base0F = "#${config.lib.stylix.colors.base0F}"

}

})

'';

But now, i get the same issue as when using stylix, so i tried of working around it by symlinking only my config folder into .config/nvim/config, so it doesn’t interact with init.lua:

home.file.".config/nvim/config/".source =

config.lib.file.mkOutOfStoreSymlink "${config.var.configDirectory}/home/programs/nvim/config";

And it works! But there is a small issue…
Instead of me telling you, just check out the output of these commands:

~ pwd

/home/user/.config/nvim/config/config/config

~ l

Permissions Size User  Date Modified Name

config -> /nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config

lua

init.lua -> /nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/init.lua

lazy-lock.json

cd /nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config

~ ls

config  lua  init.lua  lazy-lock.json

~ pwd

/nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config

~ cd config

~ ls

config  lua  init.lua  lazy-lock.json

~ pwd

/nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config/config

~ cd config

~ pwd

/nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config/config/config

~ cd config

~ pwd

/nix/store/kp8bdk7hv8fh3vbm0bihalpx2f7fcjdb-home-manager-files/.config/nvim/config/config/config/config

It seems to cause some kind of infinite (?) recursion? And i don’t know why this is happening and how to solve it.

Any ideas / solutions would be appreciated as i’m currently going insane over this.

In case anybody wants to check out the code, my nvim config is here:
https://github.com/romek-codes/dots/tree/main/home/programs/nvim

Does the out-of-store target of the symlink contain a config symlink inside it? does it ultimately point back to the same directory? This honestly seems like it’s not really related to the declarative configuration at all, but the stateful files you’re linking to.

1 Like

Hi, thanks for the answer, i went and just symlinked lua folder instead, which stopped the issue from occuring, but that is what could’ve happened.