sodiboo / niri-flake

This flake contains nix packages for niri, a scrollable-tiling Wayland compositor. You can try it right now: add the binary cache with and then . You can also try the latest commit to the branch with . This flake also contains NixOS and home-manager modules to install all necessary components of a working Wayland environment, and to let you manage your configuration declaratively, validating it at build-time. This ensures that your config's schema is always in sync with the installed version of niri. **The main location for documentation is **. The most important outputs are and . You may also use my configuration as a reference at The rest of this README covers miscellaneous topics related to this flake or repo as a whole. Feel free to contact me at in the channel or through GitHub issues if you have any questions or concerns. A note on the automated pull requests in this repository This repository uses automated pull requests extensively in order to automatically update the lockfile. If you wish to view pull requests made by humans, you can filter for . This is done in order to keep the version up-to-date. Niri doesn't have an inherent "unstable" versioning scheme (like e.g. Rust or NixOS does) and that terminology is specific to this flake. It is just the latest commit to main. It's equivalent to on the AUR. Previously, this was done by telling you to override the niri-src input with the latest version (which puts it in your lockfile), but doing it here has two main benefits: • I can run various hooks to automatically update documentation with, at the very least, the niri version, but also other generated items such as listing the available actions (parsed from source code and enumerated in ). • I can perform checks on the updated lockfile to ensure that nothing breaks with new niri updates. There are two less obvious benefits: • By requiring the build job to succeed, i can ensure that the latest niri versions are always in my binary cache before the pull request is merged. This means you won't need to build it locally. • By also automatically updating nixpkgs, i can run checks to ensure the modules keep working with the latest nixpkgs. Currently, there is no input to this flake since i felt it was unnecessary for *just* checks, and therefore configurations involving home-manager are *not* automatically tested at this time. Binary Cache I have a binary cache for this flake's outputs. hosts builds of and for and . It only contains builds for for the time being, mainly because GitHub Actions doesn't support other platforms. (and i do not wish to use qemu for this) > [!note] > This binary cache is managed by me, sodiboo. By using it, you are trusting me to not serve you malicious software. Using a binary cache is entirely optional. > > If you do not wish to use my binary cache, but still want the convenience of one, you could set , which is provided by nixpkgs. This package will receive updates slower. If you use NixOS, add the module and don't enable niri yet. Rebuild your system once to enable the binary cache, *then* enable niri. You can set to prevent this from happening. If you're not using the NixOS module, you can add the cache to your system by running . This works on any system with nix installed, not just NixOS. Using Both and provide the option to use a custom version of niri. This is done by setting to the desired derivation. If you want to use the unstable version of niri, you can set it like so: You can also set the package to the one from nixpkgs ( ), which will likely receive updates slower than the provided here. also provides the option to set the package. This won't install niri by itself, but it does set the package version used for build-time validation. Configuration of niri is the preferred way to configure niri. This is provided by , which is automatically imported when using home-manager as a NixOS module. All options are documented in . If for whatever reason you want or need to override this, you can set . You should give this option structured output from . But you can also pass it a string: or set to prevent this module from generating a config file. By default, it will generate a config file based on if it is not . For debugging (primarily development of this flake i guess), there is also which is always a string (or null) and represents the final config file that will be end up in your config directory. > [!note] > is not guaranteed to be compatible with niri versions other than the two provided by this flake. \ > In particular, this means that i do not guarantee compatibility with the one from nixpkgs at all times (i.e. when nixpkgs is lagging behind due to build failures or other reasons). \ > In practice, you will not have an issue with this unless you are running old versions of niri that are 2 or more releases behind. I will try my best not to break compatibility with nixpkgs. > > This does not apply to as it is inherently version-agnostic and still provides build-time validation. Stylix A module is provided to integrate with Stylix. To use this, the main prerequisite is that you don't ever set ; this will override everything from , which is where the stylix module places config. If you've installed home-manager and stylix as a NixOS module, then this will be automatically imported. Else, you'll have to import yourself. The stylix module provides the option to disable it: . Note that it is already disabled by default if you have set to false. When enabled, the stylix module will set the active/inactive border colors, and set to be on by default. It also sets the xcursor theme and size. Additional notes When installing niri using the modules provided by this flake: • The niri package will be installed, including its systemd units and the binary. • will be installed, as it is necessary for screencasting. • The GNOME keyring will be enabled. You probably want a keyring installed. Specifically the NixOS module provides t…