bug: xdg.configFile."../" doesn't work anymore

[jariji]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

For a long time I’ve had this home-manager config to deploy files from dotfiles/ into my home directory.

{xdg.configFile."../" = { source = ./../dotfiles; recursive = true;};}

I am upgrading from NixOS 21 to 22.11 and somehow this doesn’t work anymore: the files from dotfiles do not appear in the home directory.

I don’t see anything relevant in the changelog. What has changed? How can I fix it?

Maintainer CC

@rycee

System information

I had to roll back because of this issue, so this isn't especially useful but at least it shows the channels.

% nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.50, NixOS, 21.11 (Porcupine), 21.11.337975.eabc3821918`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(root): `"home-manager-22.11.tar.gz, nixos-22.11"`
 - channels(user): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[amodkala]

I've been fighting the same issue for the past few hours, what just worked for me was running home-manager switch without using sudo

my dotfiles repo isn't exactly up to date but it is similar to what I am using right now, if you wanted to use it as a reference

[olmokramer]

You can achieve the same result with home.file, lib.mapAttrs, and builtins.readDir:

{
  home.file = lib.mapAttrs (name: type: {
    source = ../dotfiles/${name};
    recursive = type == "directory";
  }) (builtins.readDir ../dotfiles);
}

[SpyHoodle]

Why does recursive = true; not work when home manager is run as root? It's bugging me because I can only run home manager as root, as that's how I setup my nixos config.

Seems like a bug for this not to work

[SpyHoodle]

Reboot fixed this...

[jfvillablanca]

I am also experiencing an issue with this. I'm trying to get my zellij configuration to ~/.config

zellij's default.nix has this

#home.file.".config/zellij" (also tried this)
xdg.configFile."zellij" = {
    source = ./zellij;
    recursive = true;
};

This is the directory tree for my zellij config

.
├── zellij
│  ├── layouts
│  │  └── defaultlayout.kdl
│  └── config.kdl
└── default.nix

My expected behavior is zellij/ would be copied to nix store and be symlinked to ~/.config (is that what happens under the hood?)

I had some success when I used out of store symlink to my neovim config

home.file.".config/nvim" = {
    source = mkOutOfStoreSymlink ./nvim;
    recursive = true;
};

although i am trying to avoid using out of store symlink; i just consider this to be a workaround. I am new to Nix. Some guidance would be appreciated 😀

if it helps, here's some info

❯ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.20, NixOS, 23.05 (Stoat), 23.05.20230317.b573a7f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.3`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[olmokramer]

@jfvillablanca I do something similar for my Vim setup:

    home.file.".vim".source = builtins.path {
      path = ./config;
      name = "vim-config";
    };

So in your case that would be

    xdg.configFile."zellij".source = builtins.path {
      path = ./zellij;
      name = "zellij-config";
    };

[jfvillablanca]

Thanks! I was able to troubleshoot the issue. I did not properly use Nix's module system.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.