nixos/niri: init module

[getchoo]

This adds a basic module for setting up Niri and its related services/dependencies. Options for config.kdl should be made after #295211

I tested this with the following locally and it worked well :)

{
  environment = {
    sessionVariables = {
      NIXOS_OZONE_WL = "1"; # Niri doesn't have native XWayland support
    };

    systemPackages = with pkgs; [
      alacritty
      fuzzel
      grim
      mako
      slurp
      swaylock
      xwayland-satellite
    ];
  };

  programs.niri.enable = true;

  services.greetd = {
    enable = true;
    settings = {
      default_session.command = toString [
        (lib.getExe pkgs.greetd.tuigreet)
        "--time"
      ];
    };
  };

}

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[sodiboo]

• Closes add a NixOS module to nixpkgs sodiboo/niri-flake#325 (does that syntax work at all across repos?)
• Related to Upstream this flake sodiboo/niri-flake#480 (mentioned to cause a backlink)

cc @IogaMaster @foo-dogsquared (niri package maintainers)

[sodiboo]

As it stands, a lot of niri users depend on my niri-flake to install niri (at least a dozen squared, if the star count is an underestimate). We don't want to break those systems suddenly, so the merging of this PR should be coordinated with matching changes in that flake. I already have some version matching across NixOS releases to ensure it works across incompatible stable/unstable option sets.. I'm fine with the maintenance burden of such spaghetti code, if it means a smooth transition for users on nixos-unstable. I'm a little worried at how i can detect the difference between nixpkgs where this is merged and before it's merged (eventually, it should just be based on release name, but it'd be really awesome for the niri-flake changes to be merged first, in such a way that it can handle a nixpkgs both with and without this PR merged). At any rate, it's also nice that 24.11 is coming up, so maybe that spaghetti code can be removed from my niri flake sooner rather than later.

Because this should be coordinated with niri-flake (which i maintain), do not merge this PR without my approval.

I will approve this PR eventually, once it (a) has relevant concerns addressed which are limited in scope to nixpkgs (i.e. normal review), and (b) it can be merged smoothly without breaking everything for niri-flake users. in particular, this module must be updated such that it doesn't cause build failures when this pull request is merged.

It's also worth noting that it's exam season! Which means i might take a while to respond. I'm busy with a lot of schoolwork. Still, I'm gonna try to make sure this PR and the related niri-flake changes are all done by the end of the month, so we can make it into 24.11 (deadline 2024-10-30 before ZHF), since that's gonna be a lot nicer to be able to clean without needing to wait an extra release cycle (or two? from my observations, the two yearly releases are not symmetrical, and deprecation periods seem to be handled differently, but that's just from 23.05 and 23.11; i haven't been around nixos much longer than that and don't know if that was just an abnormal year or what. point of this tangent is that not meeting the 24.11 deadline might add >6mo to that cleanup schedule. but it's not really a big deal. just nice to hit)

[sodiboo]

• Options for config.kdl should be made after formats.kdl: init #295211

We can have a config option right now as a string, i think. Afterwards, we just need to make it a types.either (types.kdl-document types.str). It's a trivial backwards-compatible change, and i did that in my niri-flake. Just within the scope of NixOS, i don't see a reason to block on the kdl PR.

The only concern with this is potentially allowing niri-flake to override that type, because it's gonna want to change the type. Adding this config option to nixos isn't inherently problematic yet, as niri-flake doesn't define it at the system-level currently. But it ought to, i just haven't gotten around to that. Because niri-flake doesn't define it currently, if we have it defined in nixos with a type = types.str, and there isn't a way to override its type (which would be useful in this case, but i don't see why it would be a thing), at the very least niri-flake could just define a separate kdlConfig option, which would later cause a warning as having been renamed to config. If we want to make sure the type is overridable, the ugliest way that ought to work is having the type of programs.niri.config be yet another option intended for use by niri-flake. I don't think that would be at all suitable for nixpkgs, but it would probably work. Is there a better way in the nixpkgs module loader to overwrite the option type declared somewhere else?

"at the very least niri-flake could just define a separate kdlConfig option" only applies here because niri-flake is lagging behind on implementing the system-level config; and if anyone wants to implement a module in the home-manager repo, this choice of having niri-flake make a separate kdlConfig option is not viable there, because niri-flake already defines the config option for its home module (this paragraph is not relevant to this pull request directly, but hopefully to anyone referencing this pull request in the future)

[r-vdp]

Hi @sodiboo. Could you include a disabledModules in your flake to disable the nixpkgs niri module (see https://nixos.org/manual/nixos/stable/#sec-replace-modules for documentation), so that we can merge this PR when it's ready without impacting users of your flake?

You are then free to either keep on maintaining your flake, or deprecate it and redirect people to the new module introduced here.

[sodiboo]

Oh, i did not know disabledModules existed. I thought I was going to have to do some awful hacks to make my module work alright with the new NixOS stuff; but just outright disabling the NixOS module would make my flake a lot more maintainable, and straight up prevent anyone's system from suddenly breaking when this is merged (because they'll have to manually switch to it).

I'll definitely just be adding that, and then most of my concerns about compatibility no longer apply.

for instance, everything I said about the hacks with providing a config option can just go out the window because no such hacks are necessary.

most of the concerns about polkit being hacky and maybe breaking systems in subtle ways no longer apply because this change will be opt in, so at the very least it won't happen just from a nixpkgs update. there remains the question of whether it is fitting to include, on the basis that no other window manage, but there's no need to be paranoid about it subtly causing issues because it's opt in.

niri-flake's primary NixOS module will probably be eventually deprecated in favor of this module, but in general niri-flake won't be deprecated because it also does a bunch of other stuff.

still, even though most of the "paranoia"-like concerns are nullified, do not merge this without my approval so I can verify that niri-flake can still work smoothly with it and there's a clear upgrade path (in general, providing a clean way to add the rest of its capabilities but use this NixOS module to actually install the package and such)

[r-vdp]

@sodiboo could you just add the disabledModules and then this new module will not interfere with your flake and we can go ahead and merge it independently?

[sodiboo]

as stated previously, a lot of my initial concerns were somewhat paranoid and based on just being afraid that this will silently cause subtle differences that lead to difficult-to-diagnose issues, and now that i am aware of a wonderful mechanism named disabledModules (sodiboo/niri-flake@48bf49e), i'm no longer afraid. that being said, i do still have some comments on a couple things about this PR more generally

[r-vdp]

@sodiboo, are we good to go here?

[sodiboo]

once this thread is resolved (#348193 (comment)), i think we'll be good. i'll approve it then.

[r-vdp]

@sodiboo @getchoo, I think we're good to merge now, right? I've been using this on my laptop for a couple of days now and everything seems to be working fine.

@getchoo I see that you decided to remove the polkit agent. I don't have a strong opinion either way, but I kind of liked the "batteries-included" idea with having the agent included by default and offering an option to disable it. I'm not familiar with how modules for other compositors deal with this though. The DEs definitely have this stuff included by default.

I don't think this is a blocker in any case, and I'm sorry about all the back-and-forth that this option has already caused, but I wouldn't mind personally if you'd re-add that part.

[sodiboo]

Yeah, good to merge (that's what "approved" means, no?). I would also approve if the polkit agent stayed; either is fine.

[r-vdp]

Yeah, good to merge (that's what "approved" means, no?). I would also approve if the polkit agent stayed; either is fine.

Yeah, I started writing that comment just before you approved.

[sodiboo]

ah, what a timing coincidence. oddly enough not the first time that happened for niri in nixpkgs.

[getchoo]

I wouldn't mind personally if you'd re-add that part.

I liked it too, but with the drop-in method I found, it's a lot easier now to do it correctly yourself

But the main reason I removed it is that it's just super specific to the KDE agent, and I found the Qt 5 version to be kinda ugly. I tried to workaround this by introducing a polkitAgent.package option, but there are too many differences between even just the main agents that it wouldn't be a good fit here; I plan on making a security.polkit.agent option to do basically this instead

EDIT: It's way easier than I thought

Most agents (including polkit-kde-agent-1) in nixpkgs have a desktop file in /etc/xdg/autostart, which NixOS will load by default. This means you can set up Elementary's agent for example with only environment.systemPackages = [ pantheon.pantheon-agent-polkit ]