-
-
Notifications
You must be signed in to change notification settings - Fork 89
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
Add global enable switches for nixos and home-manager #171
Conversation
I would argue for these to be set to false by default as in the worst case the user will have to reboot and change configuration and in the present usecase it seems that it would make a permanent breaking changes to all my systems that don't have impermenance integrated in a reliable way yet https://github.com/Kreyren/nixos-config/tree/aaf809b0212d63ad694054139a74dc97c32ff497 |
ping @0xf09f95b4 @talyz could this be merged or brainstormed? This feature is a major roadblock for my nixos configuration atm |
I'm ready to get this merged ;) I'm currently just using my fork for my projects. |
For the NixOS module, there's already an |
It might seem a bit nitpicky, but disabling all storage paths is not completely side-effect free, even I'd still really love a global enable/disable switch for impermanence. Adding individual enable options to the home-manager module would be a good idea regardless. |
It shouldn't be a problem to make it side-effect free, and if we do, I don't see the need for global switches. |
On a more complicated setup that is using various directories it's really pain to manage and i want to implement a logic that would on demand enable/disable impermanence per system, so the proposed options would make programming logic practically usable on complex setups. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Propose for alternative management of the default option
Whether to enable impermanence for home-manager. | ||
Defaults to "true". | ||
''; | ||
default = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use true
here, but add a warning to all new deployments and then change that to false
after a reasonable amount of time? Same for the option below.
Well, it's not uncommon one module to set options for another module in case the other module is enabled. In order to do this, you really need an Neither method is possible with impermanence right now, short of the user knowing to do |
But we already have Usage example: {
config = lib.mkIf config.environment.persistence.main.enable {
...
}
} or with more than one persistent storage path {
config = lib.mkIf (config.environment.persistence.main.enable && config.environment.persistence.backup.enable) {
...
}
} |
Should be solved by #189. Please check it out. |
To follow up on this, is there a specific reason this isn't implemented in home-manager or has it just not been developed yet? |
No reason, it just hasn't been developed yet. |
I'm not following. The point I made was that a module would like to set |
There's no need for |
I think that's missing the point. If an external module X creates several |
I forked the repo and implemented this commit, referencing the real life usecase: https://github.com/search?q=repo%3ANiXium-org%2FNiXium+boot.impermanence.enable&type=code So that now i can declaratively rebuild any system with impermanence and without it on demand. |
@ElvishJerricco In what scenario would an external module create @Kreyren For your use, you could just use |
The problem is that Then for users i am providing Additionally I expect the setup on system-level to get significantly more complicated with integrating Arcanyx-org/NiXium#16 |
@talyz I'm pretty tired of explaining the use case, and it's frustrating that your answer continues to be "I wouldn't be in that scenario". It's standard practice for a module to have a global enable flag. The amount of discussion on this PR is ridiculous. I'm out. |
@ElvishJerricco I was hoping that informing about the current My current stance
Usage in different, progressively more niche, scenarios
|
This is exactly what I'm talking about. This is a real "you're holding it wrong" moment. |
I've presented my take on this and shown how the current option can be used. I don't think there's much more I can do or add here, and my patience for your demands is running out. |
In #138 and #167, requests for some global
enable
option were made.I've also found some use-cases where I'd like to disable all side-effects of the
impermanence
modules for specific configurations while globally importing the modules. Though settingenvironment.persistence
to{}
generally works, it has two drawbacks:environment.persistence
and then easily globally disable them somewhere else, without forcing it to{}
(see Easy way to disable #138).This PR adds two additional options to
impermanence
:boot.impermanence.enable
: This switch is enabled by default and, if disabled, deactivates the entire module.home.impermanence.enable
: This switch does the same forhome-manager.nix
I'd rather have this module be disabled by default (as most
nixos
modules are) but this would break every current install when updating which would be very bad. Instead, these new options are enabled by default, which means current installs would not be affected at all by these changes.I put the
nixos
switch intoboot
because I felt that this module mostly affects the boot process (though some systemd services are started as well). I'm open to any suggestions for better placement.