home-manager icon indicating copy to clipboard operation
home-manager copied to clipboard

`zellij` shell integration can fail because the PATH has not yet been modified

Open poliorcetics opened this issue 1 year ago • 4 comments

https://github.com/nix-community/home-manager/blob/fb0196ad9d18554e035de27d4f2a906ba050b407/modules/programs/zellij.nix#L72-L83

For me this fails because the ~/.nix-profile/bin/ is added to the path after this, and the output produced by zellij relies on it being in PATH

I don't know if I should file a bug with zellij or here, tell me if I should go there

poliorcetics avatar Feb 10 '24 22:02 poliorcetics

For reference:

$ zellij setup --generate-auto-start bash
if [[ -z "$ZELLIJ" ]]; then
    if [[ "$ZELLIJ_AUTO_ATTACH" == "true" ]]; then
        zellij attach -c
    else
        zellij
    fi

    if [[ "$ZELLIJ_AUTO_EXIT" == "true" ]]; then
        exit
    fi
fi

poliorcetics avatar Feb 10 '24 22:02 poliorcetics

There was a change introduced in https://github.com/nix-community/home-manager/pull/5007. (edit: ah, you introduced it 😅 )

Can you share more details, please? What shell do you use? How do you install zellij? How do you configure your Home Manager? What does the error look like (if any)?

If you have targets.genericLinux.enable option set to true, the Home-Manager installed binaries should be added to the PATH in ~/.profile or ~/.xprofile or ~/.zshenv before any of this code is executed. But if you don't use the genericLinux option, I'm not sure when and where the export happens. 🤔

See: https://github.com/nix-community/home-manager/blob/bfd0ae29a86eff4603098683b516c67e22184511/modules/targets/generic-linux.nix#L59-L60

The nix.sh part exports binaries from the profile: https://github.com/NixOS/nix/blob/28a988bdde7b20abff9000162015500c44a5812b/scripts/nix-profile.sh.in#L65

https://github.com/nix-community/home-manager/blob/bfd0ae29a86eff4603098683b516c67e22184511/modules/home-environment.nix#L568

https://github.com/nix-community/home-manager/blob/bfd0ae29a86eff4603098683b516c67e22184511/modules/programs/bash.nix#L210-L211

pedorich-n avatar Feb 11 '24 01:02 pedorich-n

I'm on macOS, maybe that's the source ?

When I look at the zshrc generated by home-manager I see this:

typeset -U path cdpath fpath manpath

for profile in ${(z)NIX_PROFILES}; do
  fpath+=($profile/share/zsh/site-functions $profile/share/zsh/$ZSH_VERSION/functions $profile/share/zsh/vendor-completions)
done

HELPDIR="/nix/store/lapg988lmdl9ajs3kg4j2v8i1wlgbqdw-zsh-5.9/share/zsh/$ZSH_VERSION/help"

# Oh-My-Zsh/Prezto calls compinit during initialization,
# calling it twice causes slight start up slowdown
# as all $fpath entries will be traversed again.
autoload -U compinit && compinit

# History options should be set in .zshrc and after oh-my-zsh sourcing.
# See https://github.com/nix-community/home-manager/issues/177.
HISTSIZE="10000"
SAVEHIST="10000"

HISTFILE="/Users/alexis/.config/zsh/history"
mkdir -p "$(dirname "$HISTFILE")"

setopt HIST_FCNTL_LOCK
setopt HIST_IGNORE_DUPS
unsetopt HIST_IGNORE_ALL_DUPS
setopt HIST_IGNORE_SPACE
unsetopt HIST_EXPIRE_DUPS_FIRST
setopt SHARE_HISTORY
unsetopt EXTENDED_HISTORY

eval "$(/nix/store/<hash>-<zellij>/bin/zellij setup --generate-auto-start bash )"

# That part below I added myself because it wasn't generated automatically and I didn't have anything from home-manager in my path then
if [ -e $HOME/.nix-profile/etc/profile.d/nix.sh ]; then
  source $HOME/.nix-profile/etc/profile.d/nix.sh
fi

if [ -e /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh ]; then
  source /nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh
fi

# Other stuff

I install zellij via home-manager:

home.packages = with pkgs; [
  zellij # among others
];

programs.zellij.enable = true;
programs.zellij.enableZshIntegration = true;

poliorcetics avatar Feb 11 '24 14:02 poliorcetics

I don't have any MacOS devices to test Home Manager on, so I can't say for sure. But from what I see in the code it might look like the nix.sh part is not exported anywhere by default without genericLinux enabled. I've found multiple issues, but no definitive answer as to why is that so: https://github.com/nix-community/home-manager/issues/1646, https://github.com/nix-community/home-manager/issues/1782, https://github.com/nix-community/home-manager/issues/688, https://github.com/nix-community/home-manager/pull/797. Also might be related to https://github.com/nix-community/home-manager/issues/2012

I would suggest you add some code from generic-linux module to your config, like this: https://github.com/nix-community/home-manager/blob/21b078306a2ab68748abf72650db313d646cf2ca/modules/targets/generic-linux.nix#L59-L61

This should result in this line being added to hm-session-vars.sh which is sourced in .zshenv and .profile if you have programs.bash.enable set to true. So the PATH should already be modified before zshrc is sourced. Because in your case the nix.sh and nix-daemon.sh are sourced at the end of zshrc.

pedorich-n avatar Feb 12 '24 02:02 pedorich-n

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.

stale[bot] avatar May 13 '24 22:05 stale[bot]