Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Frontear opened this issue Sep 10, 2024 · 2 comments
Assignees
Labels
compat: forwards Represents a backwards incompatible change. Existing functionality is affected and requires fixes. priority: low Non-essential issues that are neither affecting functionality nor usability. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels. type: feature/improvement Marks the request/implementation of a feature improvement. Accompany with relevant labels.

Comments

@Frontear
Copy link
Owner

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 Frontear added the priority: mid Non-critical issues that are affecting functionality but aren't impacting usability. label Sep 10, 2024
@Frontear Frontear self-assigned this Sep 10, 2024
@Frontear
Copy link
Owner Author

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
Copy link
Owner Author

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 Frontear added priority: low Non-essential issues that are neither affecting functionality nor usability. and removed priority: mid Non-critical issues that are affecting functionality but aren't impacting usability. labels Nov 14, 2024
@Frontear Frontear added type: feature/improvement Marks the request/implementation of a feature improvement. Accompany with relevant labels. compat: forwards Represents a backwards incompatible change. Existing functionality is affected and requires fixes. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels. labels Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat: forwards Represents a backwards incompatible change. Existing functionality is affected and requires fixes. priority: low Non-essential issues that are neither affecting functionality nor usability. type: feature/addition Marks the request/implementation of a feature addition. Accompany with relevant labels. type: feature/improvement Marks the request/implementation of a feature improvement. Accompany with relevant labels.
Projects
None yet
Development

No branches or pull requests

1 participant