Need mechanism to activate sessionVariables in Wayland sessions

[colemickens]

Description

As far as I can tell there's no way, or workaround, to activate sessionVariables in a wayland session. We should rig something up, if possible. (That way I don't have to remember to start Firefox from a terminal).

[rycee]

I suspect we'll at some point switch over to importing all session variables into the systemd user sessions. And then we might as well use environment.d. Which I guess would make the variables available in Wayland?

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

[ambroisie]

Still relevant.

[auroraanna]

This is really annoying because it keeps me jumping between Wayland and Xorg. With this fixed, I could be using Wayland all the time. Using Xorg all the time is not an option because some stuff doesn't work on Xorg anymore.

[archer-65]

I'm currently using sessionVariables starting sway through greetd. I have to be honest: it works, I don't know why.

[auroraanna]

Oh, maybe this is not a Wayland problem, but a GNOME one? I've only been using GNOME to test.

[archer-65]

Oh, maybe this is not a Wayland problem, but a GNOME one? I've only been using GNOME to test.

Have you tried setting variables with systemd? IIRC, there are options for that in home-manager.

[auroraanna]

Yes I tried, didn't work either.

[auroraanna]

Gonna try out sway soon.

[archer-65]

Yes I tried, didn't work either.

That's odd...let me know if you find a solution

[auroraanna]

It works on sway for me too…

[jakobkukla]

It works on sway for me too…

Interesting. I use sway with LightDM and neither home.sessionVariables nor systemd.user.sessionVariables is working for me. Starting sway from the console works with home.sessionVariables but not with systemd.user.sessionVariables.

[archer-65]

It works on sway for me too…

Interesting. I use sway with LightDM and neither home.sessionVariables nor systemd.user.sessionVariables is working for me. Starting sway from the console works with home.sessionVariables but not with systemd.user.sessionVariables.

I used SDDM previously, same problem.

[jakobkukla]

It works on sway for me too…

Interesting. I use sway with LightDM and neither home.sessionVariables nor systemd.user.sessionVariables is working for me. Starting sway from the console works with home.sessionVariables but not with systemd.user.sessionVariables.

I used SDDM previously, same problem.

Setting xsession.enable = true; will solve this because it sources home.sessionVariables in ~/.xprofile. This is more a workaround than a solution though.

[archer-65]

It works on sway for me too…

Interesting. I use sway with LightDM and neither home.sessionVariables nor systemd.user.sessionVariables is working for me. Starting sway from the console works with home.sessionVariables but not with systemd.user.sessionVariables.

I used SDDM previously, same problem.

Setting xsession.enable = true; will solve this because it sources home.sessionVariables in ~/.xprofile. This is more a workaround than a solution though.

That works only with X sessions though, I tried a few weeks ago.

[jakobkukla]

That works only with X sessions though, I tried a few weeks ago.

Technically yes, but since LightDM (and probably most other DMs) source the file before starting sway it will work as well.

[Scrumplex]

Before switching to NixOS, I used to run Sway within systemd using a launch script like this:

$ systemd-run --user --collect --wait --unit sway -- sway

I just kept all my session variables in environment.d configurations, which worked pretty well.

Alternatively, we could switch all environment variables to environment.d and rely on something like export $(systemctl --user show-environment) (or something like that) when initializing the login shell, to continue supporting TTY logins. I think most login managers already source the environment from environment.d when starting a session, so this is only needed for people who use a TTY to start their session.

[auroraanna]

I'm for supporting TTY

[ppenguin]

I was bitten by this when switching to Hyprland (my first wayland config). It was a huge mess trying to get it to work with greetd.

Analyzing sway session handling I saw that this is handled by an explicit wrapper script, which you probably have to "hack" further (via extraConfig or similar) to make e.g. gnome-keyring env vars and such propagated.

I gave up trying to make .desktop sessions work via greeters and just made a wrapper script in the shell profile that starts the compositor when logging in on tty1, after sourcing HM vars and the like.

Maybe @Scrumplex suggestion could be a good idea because it is independent of display managers/greeters, and we have no satisfactory "wsession" equivalent for xsessions anyway currently?

[hpfr]

As far as I can tell, this already works with GNOME Wayland. See https://github.com/NixOS/nixpkgs/pull/187620#issuecomment-1891078183 for details. Perhaps the NixOS modules for other graphical session types could emulate this approach. I touch on environment.d in that comment—ultimately I think it makes sense to make users’ existing login shell configurations work for the foreseeable future. Users who really want to get rid of the call to the login shell can set it up for themselves, or make an opt-in module, I guess

[Scrumplex]

The only showstoppers for using environment.d exclusively are modules that set home.sessionVariablesExtra. Perhaps we could write a simple user unit that just sets the values in a shell script and runs systemctl --user import-environment on them

[hpfr]

Yeah I suppose for home.sessionVariables it’s easy enough to move to environment.d on NixOS since Nix manages the whole stack. I think they will still need to be added to profileExtra-type shell options for non-systemd environments like macOS, though. And some users may still be confused when profileExtra-type options don’t seem to work on NixOS Wayland sessions, but that’s out of scope here as opposed to my comment on the stale NixOS PR

[justinlovinger]

sessionVariablesExtra should probably be retired in general. It does not work for non-POSIX shells, or even shells without specific Bash-isms. It is only used in a handful of places, and programs.SHELL.initExtra could be used instead, with better compatibility for shells other than Bash. I even found bug in one of the sparse uses of sessionVariablesExtra while investigating this, a line is duplicated for home.sessionVariablesExtra and programs.bash.initExtra in modules/targets/generic-linux.nix.