Tbh I'm not sure I've fully grasped what the problem is here, but I'm am using sway from nixos with the config from home-manager and I guess as I wrote the module this is supported usage.

Any systemd parts of the home manager config are the bits I was least sure of. If you have any suggestions that would improve it (especially with respect to login managers), then I would be happy with it, if home manager maintainers are happy with it

@alexarice the relevant part for home-manager is #89019 (comment) to resolve issue nix-community/home-manager#1288 (amongst others). My suggestion would be to document the following in the enable option of the home-manager module for Sway:

• programs.sway.enable = true; should be added to the NixOS configuration (nixos/pam: add service generation for swaylock #89019 (comment) and swaylock does not unlock correctly nix-community/home-manager#1288)
• Everything else should be configured via the home-manager module (this issue)

To me, there are 2 ways to install sway with home-manager:

• Use home-manager to manage only the sway config files. In this case, the changes in this PR are needed. (or alternatively add an option to home-manager's module to install sway optionally)

• Manage sway only with home-manager. I don't like this options too much, because to me it looks like a duplication of effort between NixOS and home-manager, and also because I think it is easier to manage the integration between sway and a display manager in NixOS config. If you want to go this way, you don't need to do anything, since the default value for programs.sway.enable is false. But if anyways you want to install 2 sway versions, one with NixOS and one with home-manager, it should be possible if you have something like this in your NixOS config:

services.xserver.desktopManager.session = [
  {
    name = "home-manager";
    start = ''
      ${pkgs.runtimeShell} $HOME/.hm-session &
      waitPID=$!
    '';
  }
];

and this in your home-manager config:

xsession.enable = true;
xsession.scriptPath = ".hm-session";
xsession.windowManager.command = mySwayPackage;

2 notes: services.xserver.desktopManager.session doesn't generate wayland sessions, but it should be an easy fix, and mySwayPackage refers to the same sway package you define in wayland.windowmanager.sway.package option.

@alexarice To my understanding, systemd is not involve in this, I don't have any suggestions to improve the systemd part, it looks good to me :)
I'll try to clarify the issue with an example, let's say you have this config in you NixOS configuration.nix:

programs.sway = {
     enable = true;
     extraSessionCommands =
       ''
       export MYVAR=nixos
       '';
};

and this on your home-manager config:

wayland.windowmanager.sway = {
     enable = true;
     extraSessionCommands =
       ''
       export MYVAR=home-manager
       '';
};

after login, MYVAR value will be home-manager. As long as you mix NixOS and home-manger sway options, it is not possible to start the NixOS sway version from a display manager

I think the difficulty is that home-manager has to work on non nixos machines, and this makes it hard to integrate with nixos options.

I think the difficulty is that home-manager has to work on non nixos machines, and this makes it hard to integrate with nixos options.

Right, I didn't considered that case

This might be similar to what has already been suggested, but I think the necessary changes for home-manager are:

• Make sway.package be nullable
• Update the documentation on sway.package to say that if you are using the nixos sway module you should set this to null to avoid overwriting this

Would this fix all the issues?

@alexarice I think so, that 2 changes should solve it. But I think it still makes sense to merge this PR

I'll make a PR on home-manager then, I think this pr is probably a good idea too

Even with nix-community/home-manager#1298 one (theoretical) issue remains: When Sway is launched via a login/display manager the following options from the home-manager module won't do anything: package, wrapperFeatures, extraSessionCommands, extraOptions (more details in #89179 (review)).

If that's ok for the maintainers of the home-manager module for Sway we could merge this PR.

Ah I see the issue now, though I don't see a way round it other than putting a big warning somewhere that this overwrite exists. The home-manager module will say that setting package to null is recommended if using the nixos option

The home-manager change went through, was there any decision on what to do with this?

@alexarice no, not really. AFAIK @jlesquembre is still in favor of this PR while I'm more against it due to the problem explained in #89179 (comment) and also the resulting inconsistent behaviour between a login via a display manager or tty. I also looked at the desktop entries on my system and most files don't use absolute paths. I don't have a strong opinion on this though and I don't use a display manager anyway.

@jlesquembre if you still want this PR to get merged it would be good if you could ping a few other maintainers familiar with desktop entries and display manager (you can e.g. check the Git history). I think @jtojnar might e.g. be a good fit or actually even better @NixOS/freedesktop. If not feel free to close this PR.

I think I'm going to close this PR since now it is possible to set the sway package in home-manager to null.
The only reason against closing, it's that I prefer to be more deterministic, instead of picking the first sway version in PATH
I'm going to think a bit more about it, but if I cannot find a better reason for this PR, I'll close it

I don't know much about Sway but it seems to me that if a user chooses to set up Sway in Home Manager then they don't really want a sway.desktop but a home-manager.desktop. The HM desktop file could do something like starting a hm-graphical-session.target systemd unit, which in turn would pull in a sway.service and other graphical services the user would like.

This is sort of how the HM xsession module works but kicking off hm-graphical-session.target from ~/.xsession instead of a desktop file.

Edit: It might be worth mentioning that to do this property one would need to use the system --wait option, which does not work by default in NixOS due to its troublesome user session dbus setup. But I imagine that it would be possible to work-around by having a occasionally-check-if-sway-is-still-running-and-break-if-not loop.

The only reason against closing, it's that I prefer to be more deterministic, instead of picking the first sway version in PATH

I guess this is a matter of definition. I'd e.g. still consider this perfectly deterministic. A reference without the absolute path is just more like a global and mutable variable in a programming language while a reference with an absolute path is of course immutable as the referenced content in the Nix store is immutable (and depending on what we'd like to achieve both behaviours can make sense).

I don't know much about Sway but it seems to me that if a user chooses to set up Sway in Home Manager then they don't really want a sway.desktop but a home-manager.desktop.

HM can generate a home-manager.desktop file but unless you reference that from the NixOS configuration or patch display managers they won't find it.

HM can generate a home-manager.desktop file but unless you reference that from the NixOS configuration or patch display managers they won't find it.

That should be possible with the services.xserver.displayManager.session option, I think.

I'm closing this PR. IMO the new option added to home-manager by @alexarice is good enough and solves the problem I had. Feel free to reopen if you think otherwise.

Thanks @primeos , @alexarice and @rycee for all your comments, it was a really interesting conversation