Faciliate decoupling persistence between specialisations (or other reasons).

Frontear commented 1 month ago

Right now I have two specialisations (and I'm hoping to whip up more).

I want to faciliate persistence in all of them, but with some level of separation. For example, on Plasma I want to persist the entire .config and .local directory trees as they contain way too much of Plasma's custom files, and persisting them individually is a full-blown PITA. For something like Sway though, I only want my GPG keys persisted, nothing else.

This leads to an obvious issue that requires decoupling. In an ideal situation, files that are persisted are unique to a per-specialisation sense, where Sway things do not leak into Plasma, and vice versa.

Some problems to consider:

Some persisted entries must remain common, such as gpg keys, network configuration
How to faciliate separation (distinct my.persist.volume?)
How to provide a way for common entries to be.. well, common.

The current idea I had looks roughly like this:

my.persist = {
  enable = true; # repetitive?
  volume = "/nix/persist";

  # in /nix/persist/foo
  foo.enable = true;
  foo.directories = [ ... ];
  foo.files = [ ... ];

  # Bar will not bring its stuff in
  bar.enable = false;
  bar.directories = [ ... ];
  bar.files = [ ... ];

  # Special attr that always is enabled
  default.directories = [ ... ];
  default.files = [ ... ];
};

This can then be toggled on/off by individual specialisations and ensure distinction, while having a default that pulls in always. This idea needs incubating.

Frontear commented 4 weeks ago

This was partially improved in 737d3f3, but the underlying issue remains in that configs overlap. If I also wanted to persist ~/.config for Sway, I'd have Plasma configuration leaking, which is not ideal

Frontear commented 2 weeks ago

An implementation idea I have considered:

For the most part, system-level persistence usually stays the same across specialisations/environments, and its usually only user-level persistence that wants isolation.

Given this, it should be fine to write an extension to the persistence module that adds a new property called unique and prefix, where unique represents whether this entry should be isolated between specialisations, and prefix is the top-level path entry to prefix the rest of the entry with.

For the system-level, unique = lib.mkDefault false while for the user-level, unique = lib.mkDefault true (with notable exceptions like ~/.local/share/gnupg or ~/.ssh). In both cases prefix = lib.mkDefault specialisation.<name>, so the prefix in specialisation.plasma would be plasma.

Providing the unique interface is a good way to allow flexibility in the future if certain system state is undesirable (though I overall doubt this will be useful).

Alongside this, I should complete a re-write of the desktop modules to open up more configurables, for example, desktops.<name>.audio.enable and the like.

Frontear / dotfiles

Faciliate decoupling persistence between specialisations (or other reasons). #8