bug: Existing file '/home/foobar/.config/nvim/init.lua' would be clobbered

[lorinder]

Are you following the right branch?

• My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• I have searched the existing issues

Issue description

with the latest flake update and running home-manager switch, I get

Please do one of the following:
- In standalone mode, use 'home-manager switch -b backup' to back up files automatically.
- When used as a NixOS or nix-darwin module, set either
  - 'home-manager.backupFileExtension', or
  - 'home-manager.backupCommand',
  to move the file to a new location in the same directory, or run a custom command.
- Set 'force = true' on the related file options to forcefully overwrite the files below. eg. 'xdg.configFile."mimeapps.list".force = true'
Existing file '/home/lorenz/.config/nvim/init.lua' would be clobbered

I'm using home-manager almost exclusively to install packages into my user environment. I don't want to manage nvim's init.lua or any other config file with it. The config related to neovim in my flake is:

    programs.neovim = {
      enable = true;
      plugins = with pkgs.vimPlugins; [
        haskell-tools-nvim
        telescope-nvim
        which-key-nvim
        (nvim-treesitter.withPlugins (plugins: with plugins; [
          c lua python rust haskell bash
        ]))

        plenary-nvim        # dependency of telescope
      ];
    };

Up until now, it did what I expected: Install a neovim with the given plugins, but let me manage my own init.lua. Somehow this now changed.

Maintainer CC

@khaneliman @teto

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.18.18, NixOS, 26.05 (Yarara), 26.05.20260318.b40629e`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.31.3`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/ap9dpkyzikzzh04259wlsvha2mw455x4-source`

[lorinder]

The offending commit is 1c10e6596f2925574d0d3d1110997595a4cbf3a7

[teto]

We try to detect when to wrap the executable with the following hack:
wrapperHasUserConfig = wrappedNeovim'.luaRcContent != wrappedNeovim'.providerLuaRc;

The hack is brittle, and possibly also broken if you set extraLuaPackages since a few commits.

The wrapping of neovim is a source of many or most complaints about neovim + nix and it's also a headache from a maintainance point of view since we now have to tests 2 different approaches.

Breaking it is not intentional but help is welcome to fix it, and maybe make the wrapping explicit, as an option.
Meanwhile you can work around it by having nix write the generated config elsewhere as presented in https://github.com/nix-community/home-manager/blob/master/modules/misc/news/2026/01/2026-01-25_19-00-28.nix

[lorinder]

Ok, thank you, I very much appreciate it! I'll have a look at the workaround. Hopefully I'll get around to dig a bit more; unfortunately I'm not an expert in this area. Thanks again.

[teto]

one difficulty is that home-manager implements some things differently than nixpkgs' wrapper. We are trying to have both converge, which might make supporting both scenarii a bit easier. We are changing neovim support in nixpkgs quite a bit lately, it's a bit unstable so feel free to pin your version for a while (we try not to break things ofc but easier said than done, it's unstable after all )

[lorinder]

Potentially relevant update: I no longer see this problem. The only thing that changed from last night is that nixpkgs-unstable had an update overnight. So maybe this was a transient problem with home-manager being in sync with a slightly different branch of nixpkgs than nixpkgs-unstable? (e.g., HEAD?) If so, it seems this issue could be closed.

[teto]

with your example it's possible that the problem went away. But I am pretty sure that a similar issue can rise for instance if you set extraLuaPackages for example. This will eventually get addressed but there might be some issues in upcoming weeks.

Feel free to close (and reopen if a similar problem arises again), it might be better to have a recent report rather than a similar issue but already fixed.

[lorinder]

Makes sense. Let's close this one, then.

[lorinder]

Reopening. I just ran into this problem again. Not sure when it shows up, and when it doesn't.

[teto]

I fixed the propagation of dependencies recently, which may have triggered the generation of the file.

I am convinced we need an option if we want to keep supporting the scenario (might be doable without but explicit is easier to reason/code here).
Like a dontTouchInitLua or wrapConfiguration option. As a first step it could just avoid writing to init.lua and write into lua/home-manager-init.lua instead ? then neovim gets wrapped to load it before +c "lua require'home-manager-init"

Are you interested in contributing ?

[teto]

@khaneliman any idea for the option naming ?