Sway NixOS/Home-Manager Conflict

I’ve made significant changes to my sway config in home-manager, and I’m trying to remove as much as possible related to sway in configuration.nix.

If I remove programs.sway.enable = true; in configuration.nix , sway doesn’t appear as an option in gdm.

If I keep it, the nixos package overrides my sway-wm package overrides in home-manager.
I’m running home-manager in standalone mode.

How do I get sway in gdm while respecting my home-manager settings?

1 Like

I also have my sway configured entirely in home-manager standalone. I wanted something similar.

tldr: I don’t use a display manager (gdm) anymore I just login on the command line and run sway.

So when sway is enabled in your configuration.nix, it adds sway as a “sessionPackage” for the display manager ref. This in-turn make the session information visible to the display manager in a way it expects ref.

The big thing here is that this is all “system level” config, most if not all display managers look for info about installed desktop environments in system path. While your sway config will be in the nix store as well as your home dir after you do home-manager switch, the desktop environment does not look any of those location automatically. And from my understanding there is no reliable way for your configuration.nix to refer to any derivations in you home-manager config because they can update independently.

What would be needed is a display manager that can scan a safely scan a user’s dir for installed desktop environment configurations and show those as options, I think I heard something about maybe being able to us greetd for something like that, but I have not figured it out.

For sddm there is pretty stale issue related to this User-defined Wayland Session a la ~/.xsession (e.g. ~/.wayland-session.desktop) · Issue #916 · sddm/sddm · GitHub, and last I checked gdm does not have any functionality like that either (that might have changed, I could not tell from a quick look at the repo)

But if this would work one day this is the way I see it working. When you run home-manager switch some config about what is your default desktop environment/available desktop environments would get dumped in your home dir (maybe somewhere in ~/.config or ~/.local or something), then your display manager would scan each users dir for such config and use that info for displaying options and as instructions on how to launch the desktop environment. I think there are some security concerns with the display manager scanning things in user’s dirs.

So yeah from what I understand gdm does not do something like that, that could have changed, but I don’t personally know how to make it work.

1 Like

One idea I have for getting around the security issues, is not allowing the user to define multiple desktop-options, but just having a location for a default config in the user’s dir. Then the display manager can attempt to start the desktop environment using whatever is in the user’s dir after the user already provided creds for logging in and if there is no config in the users dir then it can fallback to a default system wide desktop environment, a terminal in the users $SHELL, or fail to log in and go back stay on the login screen. This way the display manager does not need to read users dir’s before they login and it can entirely deal with the data in the users dir as the user and not as root or something.

This would mean the user would not see “sway”, “waybox” or whatever as options in the login screen and instead just see “Default”, but it seems do-able, maybe even with greeted. (I dont know much about greeted so don’t take my word for it)

This already exists, it’s the .xsession script, which home-manager should set up by default. The nixos session start scripts will invoke it by default if it’s set (maybe even instead of the chosen DM?), I believe, but I forget the details - there’s a surprising amount of code there.

Not sure about gdm, I make lightdm run my xsession like so: https://github.com/TLATER/nixos-hosts/blob/a6e5e04109f3b54c3c949902fa2840e67738e29a/configurations/default.nix#L113, with this xsession config in home-manager: https://github.com/TLATER/dotfiles/blob/129c28a827cd7a35442c3000c599909662f5b8c7/nixpkgs/configurations/graphical-programs/stumpwm.nix#L45

Chances are something similar will work with gdm, but I encourage you read the session scripts for yourself if it doesn’t :wink:

The best way to resolve this might be to add an option to the NixOS module in a new PR. If we had a programs.sway.package we could then set it to the one home-manager is using with programs.sway.package = config.home-manager.<user>.wayland.windowManager.sway.package

1 Like

That would not work for me or @jevy, as we are using home-manger in standalone mode.

is there a good reason for that? The official doc reccomends using the NixOS module and setting:

        home-manager.useGlobalPkgs = true;
        home-manager.useUserPackages = true;

To ensure that the same version of pkgs and user packages are kept in sync between the two. I’m not even sure that using it standalone on NixOS is supported officially. In any case, I would personally urge you to just use the NixOS module.

If there is some benefit to this that I’m not aware of (never tried it) you could still use the nixos-module and re-export the home-manager segment (from a flake, for example) to use via the stand-alone interface. That way you could still cross configure the two and maintain the standalone mode. We did this in DevOS, for example, so that home-manager configs defined for NixOS could be re-used on other system.

I am curious possible solutions, but I have to admit that I don’t understand what you exactly suggest.

From a high level, home-manager just wants to evaluate a module, whether that module exists as a submodule of some higher order module system (i.e. NixOS) or independant doesn’t really matter. I’m not sure how your configuration is structured so I can’t say a whole lot off hand, but you could point home-manager cli at the value of home-manager.<user> from your NixOS config (assuming actually make use of the NixOS module and define all your home-manager bits in tandem) and it could evaluate it just the same as if you had kept them seperate, however the benefit in doing it this way is that you can share values between the two.

Sorry if that’s too vague, it’s been a very long time since I’ve used the home-manager cli so I can’t remember the exact semantics off-hand, also I’m not sure if you are using flakes or not, but with flakes you could simply do something like homeModules = { inherit (nixosConfigurations.your-config.config.home-manager) user; } to export your user as its own indendant module consumable from the hm cli, for example.

In any case this is a bit off topic, so as an apology for derailing the conversation, here is the aforementioned PR, maybe this will help you get it working?

So as an update, I just shifted my setup to include the NixOS module and it works really well. Having it all updated together does obviously help things.

For folks landing on this thread via web search, there is now a programs.sway.package option in unstable.

To use whatever is in the path (HM provided):

programs.sway.enable = true;
programs.sway.package = null;