bug: sway from home-manager doesn't see home-manager packages

[dmayle]

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

I'm using home-manager on top of debian and have a mostly working sway config. Unfortunately, sway is unable to see any home-manager installed binaries, which has a couple of problems.

The first is that you have to use a full path with swaymsg exec. I've worked around this by generating key bindings from home-manager and referring to the full package path.

The second is that my launcher is unable to see home-manager binaries, but even if it could, it could not launch them. My sway config uses wofi with dmenu_path to pipe an argument via xargs to swaymsg exec. By default, dmenu_path pulls binaries from the path to search for, so it doesn't see home-manager binaries. Even if I run dmenu_path manually from a terminal emulator (which allows it to see my home-manager path), then when I send the message to sway via swaymsg exec, it's unable to find them to launch.

Maintainer CC

@alexarice @sumnerevans

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.10.46-5bookworm1-amd64, Debian GNU/Linux, 12 (bookworm)`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4`
 - channels(dougle): `"home-manager, nixgl, nixpkgs-21.11pre332093.7fad01d9d5a"`
 - nixpkgs: `/home/dougle/.nix-defexpr/channels/nixpkgs`

[berbiche]

Hi,

Looks like the solution would be for Sway to be started from a login shell.

What login manager do you use? IIRC there was a bug where GDM did not source the profile/shell of the user, resulting in missing environment variables. I think this bug only affects non-NixOS systems.

[dmayle]

By digging into the generated .bashrc and the files it calls, I was able to work around this by adding the following to extraSessionCommands:

export PATH="$HOME/.nix-profile/bin:$PATH"

[dmayle]

@berbiche I'm using gdm as the login manager

[dmayle]

@berbiche it seems that gdm uses .profile, and not .bashrc, and .profile contains the following line:

. "/home/<USER>/.nix-profile/etc/profile.d/hm-session-vars.sh"

This gets home manager session variables as specified by the user, but not the path

[berbiche]

GDM issue is documented here: https://github.com/swaywm/sway/issues/3109

Maybe we could force the Sway package to source hm-session-vars? You were quicker. You could use extraSessionCommands IIRC for Sway to source things before starting Sway.

[berbiche]

@dmayle do you have targets.genericLinux enabled?

It sets the path correctly (through nix.sh): https://github.com/nix-community/home-manager/blob/e28185a2c062e7d77fd2a71678a75ce7a2eeb6fe/modules/targets/generic-linux.nix#L46-L51

edit: There is also home.sessionPath that could be of interest. See https://nix-community.github.io/home-manager/options.html#opt-home.sessionPath

[dmayle]

@berbiche I do have it enabled, and now that I look, I see that line in .profile, but despite having the variable LOCALE_ARCHIVE_2_27 set correctly in my sway environment, and it seems to only come from hm-session-vars, I don't have the correct PATH in sway environment.

It's truly baffling

[dmayle]

I think I've got it... I'm not getting .profile, I'm getting systemd session variables, because of the following line in i18n.nix:

systemd.user.sessionVariables = localeVars;

[berbiche]

@dmayle A workaround for this issue specific to GDM would be to source HM's session variables in https://nix-community.github.io/home-manager/options.html#opt-wayland.windowManager.sway.extraSessionCommands

extraSessionCommands = ''
  [ -f "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh" ] && . "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh"
'';

[witchof0x20]

Another possible workaround, added to system config:

services.xserver.displayManager.sessionPackages = [
    ((
            pkgs.writeTextDir "share/wayland-sessions/sway.desktop" ''[Desktop Entry]
Name=Sway
Comment=Sway run from a login shell
Exec=bash -l -c sway
Type=Application''
    ).overrideAttrs (oldAttrs: rec {
      passthru = {
        providedSessions = ["sway"];
      };
    })
    )
  ];

Very hacky but it just builds a custom package providing a custom display manager session that does bash -l -c sway instead of sway This is the only reference to sway in my system config, and I use the home-manager config for everything else. The executable spawned by this is managed by home-manager (because the login shell sets up PATH).

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

[hakan-demirli]

The same issue on Arch Linux, installed via archinstall: sddm+Hyprland Packages installed are not in PATH.

I use use-xdg-base-directories = true on nix.conf

Workaround:

  home.sessionVariables = {
    PATH = "~/.local/state/nix/profile/bin:$PATH";
  };

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