Launched terminal shell has no `home.sessionVariables` when using systemd service

[onemoresuza]

Description

This was tested using the home-manager module.

When using xremap through a systemd service, the launched terminal has none of
the variables defined in home.sessionVariables. I believe this is expected
behavior, since systemd services have access to a limited number of environment
variables. Likewise, any other program launched by xremap also does not have
access to them.

I'm not creating this issue looking for a solution, since I already found one:

{lib, pkgs, ...}:
{
  programs.bash.initExtra = lib.mkOrder 99 ''
    if [ -n "$__SHELL_FROM_XREMAP" ]; then
      . ${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh
    fi
  '';
  systemd.user.services.xremap.Service = {
    EnvironmentFile = builtins.toString (
      pkgs.writeText "xremap-session-vars-as-env-d" (
        builtins.concatStringsSep "\n" (
          lib.mapAttrsToList (n: v: "${n}=\"${builtins.toString v}\"") (
            config.home.sessionVariables // { __SHELL_FROM_XREMAP = 1; }
          )
        )
      )
    );
  };
}

What it does is expose the session variables to the service, while also adding a
check for the shell --- in this case, Bash --- to source the session variables
if called from xremap, since they are source on ~/.profile, which is not
sourced in such case, since there's no login.

That last part is needed for the shell to avoid /etc/profile or the shell
specific --- in this case, /etc/bashrc --- overriding the session variables
exposed to the service, since they are being sourced on the shell call, that is,
after the session variables were exposed to the service environment.

I was wondering if it would warrant a section in the docs/HOWTO.md; an
addition of an option to the home-manager module to apply what was described in
the solution --- be happy to make the PR in any of those two cases ---;
or just the closing of the issue for being to much of an edge case.

[VTimofeenko]

I believe this is expected behavior, since systemd services have access to a limited number of environment variables

Correct. this would apply to any application launched from systemd. Another way to do this would be to set relevant variables using systemctl [--user] set-environment

There's already a (perhaps, confusingly|narrowly named) section dedicated to $PATH in the docs: link with an alternative solution that does not apply to all DEs -- use hyprctl or its analog to signal the DE to start a process. The process would inherit variables from DE instead of systemd.

[onemoresuza]

I've created a PR adding a section on environment variables to docs/HOWTO.md.