niri: include optional doesnt work

[JumpIn-Git]

hey, i have a very wierd question…

im using niri with a regualar .config/config.kdl right now, i want to move to wrappers.
the problem is, i use noctalia-shell and want to include the generated colorscheme file it provides (.config/niri/noctalia.kdl).
i dont think include in the wrapper can access out of store stuff, am i misunderstanding or do i need to make a out of store symlink?

(also asked in forum, will ask here too)

[BirdeeHub]

You should be able to include the file via an include statement.

However it may cause the niri validate check to fail.

If it does fail, disableConfigValidation = true; will cause it to just make the file and not try to verify correctness of the config at build time.

[JumpIn-Git]

doing just include = "/home/cinnamon/.config/niri/noctalia.kdl"; doesnt work it brings up a error of it not existing (sandboxed?) ill try that or extraConfig

[BirdeeHub]

doing just include = "/home/cinnamon/.config/niri/noctalia.kdl"; doesnt work it brings up a error of it not existing (sandboxed?) ill try that or extraConfig

Did you do disableConfigValidation = true;? The only thing that should be actually checking that path at build time is the validation step.

Disabling it trades build time error messages about missing or incorrect fields, in exchange for not checking included out-of-store-paths at build time.

It simply runs niri validate on it, so, you can do that at runtime if you still want to see the error message it would have given if any.

[JumpIn-Git]

no i would rather avoid that i tried optional imports (also in extraConfig), they all get checked by niri validate even if its optional... seems like i have no choice

[BirdeeHub]

Unfortunately, yeah if it checks the include paths at build time, and you use a runtime path that isn't there at build time, then yes, you would have to disable that, or it would fail and not build.

I think there is likely a good way to have some kind of impureIncludes option or something, and have it point to a placeholder path that is a blank file when the validate is run, and then populate it to contain all the impure include statements after the validate command... You would also have to slightly change how disableConfigValidation works so that it only disables the validate command and not the whole installPhase

Maybe that would be good to add? @patwid (or @JumpIn-Git too, if you feel up to it) do you want to give it a shot or should I?

^ you could still do that, but using their optional thing would be better.

[JumpIn-Git]

im not as experienced with nix, took me 20 minutes just to find out how to add optional=true to include, but honestly this seems more like a incosistency with niri validate; should i make a issue?

[BirdeeHub]

they have an include optional thing? I don't use niri so I don't know 100% of their options. If they have an include which is meant to be optional, and validate still throws if it isnt there, then yes that is a bug and they should know about it. Filing an issue would be appreciated (include the generated config file for them to look at too of course, don't make them look at nix if they don't want to, but also include the context from here so they know why it matters)

It runs it here:

nix-wrapper-modules/wrapperModules/n/niri/module.nix

Line 344 in 81701c9

${lib.getExe config.package} validate -c ${config.constructFiles.generatedConfig.path}

[JumpIn-Git]

yeah thats exactly what i mean, will make a issue tmrw

[BirdeeHub]

Also, to be clear, it is not that weird of a use case 😄

[patwid]

Weren't optional includes introduced just recently in the latest release (26.04): https://github.com/niri-wm/niri/releases/tag/v26.04 ?

The official nixpkgs still provide the 25.11 release though.

[BirdeeHub]

Oh!

Maybe if we pull from the flake?

[BirdeeHub]

@JumpIn-Git would you mind sharing your config? Have you tried pulling the package from their flake and setting config.package with it?

[BirdeeHub]

Ok, so I just tried it out. It seems to work... but only if you pull from the flake.

But the includes options leave a bit to be desired. We should add something for that.

Because I can

  include = [ { optional = true; } "~/.config/blehIamnothere" ];

which is really nice and all... but I can only do it once.... because this is a set...

So anything more than that and I am using extraConfig

It would be kinda nice if we could somehow get the ability to also include a list of auto translated values to get added to the ones from the settings set? extraKdl or something and have it take a list of sets?

Cause then we could

config.whateverwenameit = [
  { include = [ { optional = true; } "~/.config/blehIamnothere" ]; }
  { include = [ { optional = true; } "~/.config/blehIamnothereagain" ]; }
];

[BirdeeHub]

On the version from nixpkgs

     Last 25 log lines:
       > Running phase: buildPhase
       > Running phase: installPhase
       > Error:   x error loading config
       >   |-> error parsing
       >   `-> error parsing KDL
       >
       > Error:   x unexpected property `optional`
       >     ,-[niri-config.kdl:48:1]
       >  48 | }
       >  49 | "include" "optional"=true "~/.config/blehIamnothere"
       >     :           ^^^^^|^^^^
       >     :                `-- unexpected property
       >  50 | "layout"  {
       >     `----
       > Error:   x failed to read included config from "/nix/store/
       >   | xccyqsibzwrsr4nb526mhp096yrzp4cr-niri-25.11/~/.config/blehIamnothere": No
       >   | such file or directory (os error 2)
       >     ,-[niri-config.kdl:48:1]
       >  48 | }
       >  49 | "include" "optional"=true "~/.config/blehIamnothere"
       >     : ^^^^|^^^^
       >     :     `-- node starts here
       >  50 | "layout"  {
       >     `----

On the version from the flake tho, it builds.

So, @JumpIn-Git don't file an issue on niri-wm

Instead, go try to update the niri package in nixpkgs, and if you can't, file an issue there for them to update. (search for PRs and issues for it already first, so that if there are some, you can boost it instead)