niri: add target

[trueNAHO]

I assert that this feature request is relevant for Stylix

• [x] I assert that this is not a duplicate of an existing feature request.

Description

Niri is indeed not supported directly by stylix, but the popular niri-flake has a stylix module for niri: https://github.com/sodiboo/niri-flake?tab=readme-ov-file#stylix

-- https://github.com/nix-community/stylix/issues/1742#issuecomment-3108272618

@sodiboo, it might be good to move your Stylix module into our tree:

{
  lib,
  config,
  ...
}:
let
  inherit (lib) mkDefault mkIf;
in
{
  options.stylix.targets.niri.enable = config.lib.stylix.mkEnableTarget "niri" true;

  config = mkIf (config.stylix.enable && config.stylix.targets.niri.enable) {
    programs.niri.settings = {
      cursor = mkIf (config.stylix.cursor != null) {
        size = mkDefault config.stylix.cursor.size;
        theme = mkDefault config.stylix.cursor.name;
      };
      layout.focus-ring.enable = mkDefault false;
      layout.border = with config.lib.stylix.colors.withHashtag; {
        enable = mkDefault true;
        active = mkDefault { color = base0D; };
        inactive = mkDefault { color = base03; };
      };
    };
  };
}

-- https://github.com/sodiboo/niri-flake/blob/fdeb0c5367f6e183f19ee1521644cb0440582bde/stylix.nix

External inputs should be added similar to:

• https://github.com/nix-community/stylix/blob/f6c5aaa4f8b70ec0bf995be43311c38be3131776/modules/neovim/nixvim.nix#L150-L151
• https://github.com/nix-community/stylix/blob/f6c5aaa4f8b70ec0bf995be43311c38be3131776/modules/neovim/nvf.nix#L25-L27
• https://github.com/nix-community/stylix/blob/f6c5aaa4f8b70ec0bf995be43311c38be3131776/modules/spicetify/spicetify.nix#L14
• https://github.com/nix-community/stylix/blob/fbe1dab7783a3d579dc57be8ceee148104e0930b/modules/zen-browser/hm.nix#L23

According to the following commits, @danth and @sodiboo should be marked as authors (or Co-authored-by:) of this module:

• https://github.com/sodiboo/niri-flake/commit/43c8f5c8687e992f10d62928ddebba8cfec87589
• https://github.com/sodiboo/niri-flake/commit/745bfd9db78c9a916933fd9389c3bc78f418cc8d

[sodiboo]

Oh, neat! I didn't even realize stylix supported styling non-"part of upstream home-manager" modules from this repo.

That's cool. Yeah, that module should probably be just placed in stylix then.

We'll need to be careful about not stepping on the toes of a potential upstream home-manager niri module. I reckon i should create a draft PR there with what i want that module to look like; partially as an example consumer of https://github.com/NixOS/nixpkgs/pull/426828, and partially just so i can make it crystal clear that "stylix depends on settings being from niri-flake, do not add it into home-manager without serious consideration".

[sodiboo]

I have started cooking up that placeholder home-manager PR and realize it probably wants niri to go in a different namespace: wayland.windowManager.niri.

So, it's probably safe to assume that programs.niri in home-manager is unambiguously niri-flake? Still, i'm not loving the idea of just assuming that.

[trueNAHO]

Oh, neat! I didn't even realize stylix supported styling non-"part of upstream home-manager" modules from this repo.

That's cool. Yeah, that module should probably be just placed in stylix then.

We'll need to be careful about not stepping on the toes of a potential upstream home-manager niri module. I reckon i should create a draft PR there

The previously mentioned external input support pattern allows moving your Stylix module into our tree without having to wait on Home Manager integration. Once Home Manager has a Niri module, we can change our Niri module to leverage that Home Manager module. Might be neat to do this in the meantime.

[sodiboo]

without having to wait on Home Manager integration

Yes. I realize. I was more thinking in case home-manager gains a programs.niri with a subtly incompatible schema. I don't want that to cause issues down the road. I wasn't planning on trying to get merged in home manager before doing anything in stylix; I merely wanted to "reserve" the name by making a draft PR, so I can ensure that whatever does merge is not gonna break stylix. But then I realized that theirs will be wayland.windowManager.niri; so it's not a concern at all.

[danth]

It seems like the intention is for niri-flake to become obsolete once an upstream Home Manager module is in place, so it makes the most sense to me to just leave its Stylix module where it is for now. That way, we don't have to deprecate code from Stylix later on. Also, moving it would make older versions of niri-flake incompatible with newer versions of Stylix, as they would have conflicting modules.

[sodiboo]

It seems like the intention is for niri-flake to become obsolete once an upstream Home Manager module is in place.

the intention is for niri-flake to continue to be an exhaustive mapping of niri's configuration to idiomatic Nix modules. stylix can continue using this.

the other parts of niri-flake (in particular, the "installation" parts of the NixOS and home-manager modules) are intended to be obsolete eventually. (arguably, the NixOS module is obsolete already, i just don't communicate this clearly and haven't marked it as deprecated yet)

Also, moving it would make older versions of niri-flake incompatible with newer versions of Stylix, as they would have conflicting modules.

the way most of niri-flake's settings are mapped out, is that i try to ensure "default" configs result in empty documents as much as possible. for instance, if you set no environment variables at all, then the environment section isn't emitted. it's not 100% of the way there for all sections of the config, but environment was changed to act this way here, and eventually i want to make essentially the whole thing like this.

so, in the dreamy future state of niri-flake, there is no reason to use the older versions of niri-flake, because it is just a settings mapping, and the newest version should work to configure older versions of niri.