use xdg.systemDirs.config instead of directly writing the files

[Noodlez1232]

When writing the config files in write_config.py we can instead perhaps use something like this (mostly pseudocode):

thisConfig = conf: pkgs.mkDerivation let
    confAsJson = convConfToJson conf
in
{
   nativeBuildInputs = [ writeConfigScript  ];
   installPhase = ''
      # python script modified to write to $out instead of .config
      write_config ${confAsJson}
   '';
}

# later in configuration
xdg.systemDirs.config = [ (thisConfig processedConfigAttrs) ];

This moves the config files to the nix store, and allows them to be managed as such. Then any overwriting that wants to be done by the user can be done in their own dotfiles.

This leads to two main benefits:

• To revert back to what is declaratively given, just simply remove the dot files in the .config directory.

• Immutability and Reproducibility. This is the main benefit here. The files are then stored in the nix store, and therefore are managed by nix. (e.g. people having their nix store separately but shared, etc.)

[Noodlez1232]

Oh a benefit not mentioned here. Settings changed in the settings panel can be left alone as well between updates. Perhaps there could be a setting in programs.plasma called force that will always delete the given files in the .config directory so it's always reverted upon activation.

[magnouvean]

Interesting suggestion. This could work for some files I think but a lot of plasma files would need to be mutable as kde plasma writes to these files often even when not changing the settings I believe. Regarding force setting there already is a overrideConfig, which I think does mostly what you want (though it is not well documented I know, this will change soon hopefully :)).

[magnouvean]

I might be misunderstanding something here though, I haven't really heard of xdg.systemDirs option before. I might need to check it out further

[magnouvean]

If what I understand correctly is that the nix store config-files will be read if they are present and ignore the ~/.config files, it could work. Hopefully such an approach doesn't introduce bugs caused by config-keys written to files in ~/.config by plasma being ignored, but maybe not. This needs some exploration I reckon.

[Noodlez1232]

The way xdg.systemDirs works is it adds the dirs given to the $XDG_CONFIG_DIRS variable. The way this works is that they end up getting read and put at lower priority than $XDG_CONFIG_HOME (usually ~/.config).

This means any settings in ~/.config are applied and OVERWRITE any config done in the nix config.

The idea here is this lets users safely apply their own changes on top of the config given by plasma-manager. And if they decide they want to revert to their declarative setup, they can just simply delete the files in the ~/.config directory.

This is why a force option would be needed, since the plasma-manager files are then made lower priority than the users' config files.

[Asqiir]

I can only speak about kate, but I know that the katerc needs to be mutable: otherwise, kate can't remember anything, e.g. the recently opened files.

[Noodlez1232]

That's the benefit here.
We benefit from the immutability that nix gives, but all files in ~/.config stay mutable.

Of course we'd need to find out which programs do and don't listen to $XDG_CONFIG_DIRS.
I'll do that today as well (once I get back from school)

[magnouvean]

Wouldn't that then mean kate wouldn't be able to write to its config-file though as that is immutable (it's in the nix store after all). That could probably result in some errors. Or alternatively if it tries to write to .config/katerc it will create that file and then completely ignore the configs written by plasma-manager.

Another problem is if the nix-store directory has a lower priority, then if the user already has config-files present in .config before trying plasma-manager then the configs wont be applied unless they remove those files due to them having higher priority, which I think is more confusing than it needs to be. Ideally the plasma-manager configs should have a higher priority than the ones created by kde (I don't know if that's possible).

[Noodlez1232]

This is precisely why I mentioned a force option. The idea behind this option is that it'll simply delete the files in the ~/.config directory. We could even make it true on default to help alleviate it. OR, we can remove the options that are changed by the configs, just like it is now, although you're right, this is pretty complex.

Of course, this is still modifying the ~/.config directory, which is what this is trying to avoid (to a certain degree).
Mostly, though, I'm trying to get these files stored in the nix store, because there's a lot of benefit of that (rollbacks, storing them remotely, remote building, etc.)

[Asqiir]

@Noodlez1232 I do not think that would be a good idea. For example, kate would forget the recently opened files on each activation.

In the current setup, plasma-manager overrides only those settings that are explicitly set and leaves everything else alone. That second part is important.

If we could somehow make the first part permanent instead of setting it time and time again on each activation that would be perfect, but in the meantime the current solution is goos enough.

[Asqiir]

I just thought of another way: (not sure if this belongs here)

We could make the activationScript keep some, prespecified options. That means, reading the values from the old file and writing them to the new one.

[Noodlez1232]

I wonder if we can modify the files and pull the options that are changed out of the files? So, if we change kderd5rc."Module-device_automounter".autoload = false, we can go through the files, pull these options out of them, therefore removing the configuration of it, and yet leaving the original files alone. This way, if it fails, it fails more in the direction of keeping what was already there instead of the nuke option of removing the existing files.

[quentinmit]

What happens if you mark a key as immutable in a systemDir? Does that override any settings in ~/.config, or does it only prevent any new instances of the key in ~/.config, or neither??