bug: starship wrong path if `use-xdg-base-directories = true` is set

[hakan-demirli]

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

Removing use-xdg-base-directories = true solves the issue. However, this is just a workaround. Error: bash: /home/USERNAME/.nix-profile/bin/starship: No such file or directory

home.nix

  programs.direnv.enable = true;
  programs.bash.enable = true;
  programs.starship.enable = true;

.config/nix/nix.conf

experimental-features = nix-command flakes
max-jobs = auto
use-xdg-base-directories = true

Another user also mentioned encountering a similar issue with the fish shell. https://github.com/nix-community/home-manager/issues/2316#issuecomment-1712025562

Maintainer CC

@rycee @marsam

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.1.69, NixOS, 24.05 (Uakari), 24.05.20231222.6df37dc`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[hakan-demirli]

Looks like this PR https://github.com/nix-community/home-manager/pull/4422#issuecomment-1859149515 addressed the issue. However, I am using the latest commit so maybe the problem is smth different.

    "home-manager": {
      "inputs": {
        "nixpkgs": [
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1703368619,
        "narHash": "sha256-ZGPMYL7FMA6enhuwby961bBANmoFX14EA86m2/Jw5Jo=",
        "owner": "nix-community",
        "repo": "home-manager",
        "rev": "a2523ea0343b056ba240abbac90ab5f116a7aa7b",
        "type": "github"
      },
...

[hakan-demirli]

I just noticed It also created a symlink from my home dir to nixstore ~/.profile -> /nix/store/m9y2zla1ywzbwyrszym20p1rmfdrgi76-home-manager-files.config

I think this shouldn't have happened since use-xdg-base-directories = true enforces xdg base specification and profile should be in ~/.local/state/nix. The symlink in .local/state/nix ends up here: /nix/store/0vi1w3vc2xzxvlplvwgyq5lwxlqa0q5f-user-environment

Also I am not sure if there is a reproducibiliy problem when nix.conf is edited or this is something expected since it is outside the flake but removing use-xdg-base-directories = true doesn't immediately fix starship. ~/.nix-profile is created but it is empty. There is no bin folder so it fails. I have to first remove the lines above from home.nix, rebuild switch, then add them again and rebuild switch. Otherwise no /bin is created inside ~/.nix-profile .

Everything is ok if you don't meddle with use-xdg-base-directories = true though.

[worldofgeese]

I've replicated this across two machines, both a MacBook Pro M2 and an x86 laptop running WSL. I think use-xdg-base-directories is a red herring as I don't have it listed in ~/.config/nix/nix.conf. My guess is it's brand new installations of Home Manager that will run into this issue.

There is no bin folder so it fails. I have to first remove the lines above from home.nix, rebuild switch, then add them again and rebuild switch. Otherwise no /bin is created inside ~/.nix-profile .

@hakan-demirli, I'd hazard to guess this was the real fix. The first init will leave users of starship with a mangled shell that repeats bash: /home/USERNAME/.nix-profile/bin/starship: No such file or directory. If programs.starship.enable is set to false, Home Manager is rebuilt, starship is set back to true, then Home Manager is rebuilt again, it will yield a usable shell.

[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.