Immutability behaviour

[Asqiir]

I know I'm late to the party – #94 was merged quite a while ago – but it took me some time to make up my mind on this topic. (My first thoughts were in #92.)

In my opinion, the general topic of (im)mutability in the config files is handled inconstently at different points in this project. I want to share my opinions and understand yours so that we (hopefully) can reach a consensus before the next breaking changes on this topic.

I will post each of my opinions as single posts below so that you can respond to each one separately if you want.

We handle

• the immutable setting for each key
• and the reset script.

Short notice on the words use to describe specific things:

A config file is any file managed through config.programs.plasma.configFile.

A key is any config.programs.plasma.configFile. .... See the description of #93 for reference. It uses the word key in the same sense as here.

The nix config is the entire configuration (written in nix) whose activation installs plasma-manager.

A plasma config file is a file created and used by KDE plasma, e.g. dolphinrc.

[Asqiir]

Opinion 1: If a value is set explicitely, it should be immutable (by default)

The nix config is an abstraction layer between the user and plasma config files. I expect users to interact with the nix config, and not with the plasma config files directly. Making all key immutable means that a setting can not be inconstent between the two configs, except if explicitely configured as mutable. This will spare all users' of long bug hunts down the line.

[magnouvean]

I do sort of agree there. It could limit a lot of options in the kde settings app though. A good thing about having it enabled though other than it making more sense is that we then won't overwrite keys since adding a line key[$i]=value wont erase key=value existing there before. Setting immutability by default is really easy as well as it should just be to set the immutable option for the files module type to default to true. We should at the very least make an option for this. Whether it's the best to have it on by default I'm not sure. I think it could very well be enabled by default, but I'm not sure what the consensus is outside of my opinion.

[Asqiir]

Is there any reason for us not to modify the script such that key=value gets deleted when setting key[$i]=value?

[magnouvean]

I think it honestly is a plus that it stays there as then, when a configuration is removed from plasma-manager, the setting goes back to what it was before it was configured in plasma-manager

[Asqiir]

Opinion 2: Mutable variables should not have an explicit value in the nix config

A key being mutable means that plasma can change it on its own. Therefore the user should not expect it to have any specific value. That is why there should be no value for it in the nix config.

Some kind of explicit key = mkMutable notation (which then evaluates to some keyword) might be useful to explicitely variables as such. The error case where one program expects a key to be mutable and another tries to set a specific value can be detected at compile time.

[magnouvean]

I'm not quite sure I get what you mean here. If a key isn't set in some config-file it is already mutable by default as kde can already set files to whichever value it pleases without plasma-manager bothering at all. If you want to write a key using plasma-manager to be mutable you could just set immutable = false explicitly (which is the default a.t.m.). I don't really see the point in including something in the nix-config if it doesn't do anything.

[Asqiir]

My point was: "there is no point in setting a value when also setting immutable = false" (and thus, we maybe should make these two mutually exclusive (?))

Also, it might be a useful abstraction such that we can change the mutability behaviour later without breaking users code.

mkMutable could currently e.g. evaluate to { immutable = false; }.

[magnouvean]

I guess it's just for prettiness/order of the config. I would have thought you already could set something mutable without setting the value, but maybe I am wrong. It should be that way anyway. As for mkMutable I think that could just as well be declared in the let-block of the nix-files for those who want them.

[Asqiir]

Opinion 3: All keys should be mutable and persistent by default

A key being mutable means: plasma can change its value.

A key being persistent means: it isn't changed on activation of a new nix configuration.

Without plasma-manager, all keys are mutable and persistent. This is what plasma expects. That is what our default settings should match.

[magnouvean]

Doesn't this conflict with opinion 1. Also, this is what plasma-manager currently does if overrideConfig is disabled. Having persistence also means that we won't have a declarative config, which is why overrideConfig is an option for those who want that.

[Asqiir]

By "mutable and persistent by default" I mean the keys not set through plasma-manager. (As in "we should not reset/modify them".)
(This matches the current state, I just wanted to explicitly write it down.)

[Asqiir]

Opinion 4: Allow reset by key

plasma sometimes explicitely uses the "mutable and persistent" behaviour, e.g. for storing paths to recently accessed files. Even when resetting all (not expclitely defined) keys is desirable, it would be good to be able to define some keys that shall not be reset. I imagine either having a list (per config file) containing all the keys that should not be reset, or setting something like key = mkPersistent. (This could be the same as the mkMutable in opinion 2.)

From the technical side, I think changing the reset script should do the trick.

[magnouvean]

This I agree would be nice. We probably in not so long time will make some improvements to overrideConfig so this should be a priority then as it will fix some bugs in plasma 6.

[siryoussef]

I was really glad when I found options for immutability (immutableByDefault) & declarativity (overrideConfig) but even with both enabled , the immutable behavior is missing something I think is very important, regular nix config options symlinks files from nix store , plasma manager never does so even with both options enabled , I get why each option alone is not implemented to do so , but I think if both options are enabled , all config files should be symlinked from nix store as any other home-manager option, that would make the environment pure & avoid issues as permission errors & would align better with most nix environment (in my case I wanted to configure an InRAM-Home environment with the only home-manager option not working after enabling are plasma manager one's), maybe there should be a 3rd option that does so

[magnouvean]

We could consider adding this as a separate option maybe. I would say it's quite dependent on how kde plasma deals with this though as it will frequently want to have write-access to these files, and I'm not 100% sure if all settings will apply correctly if it doesn't have this (but maybe it's not a problem for all I know). It also doesn't make sense for plasma-org.kde.plasma.desktop-appletsrc as this will need write-access as it's written from desktop scripts.