| 29 Jun 2025 |
 emily | tbh, the OpenConnect thing probably should actually be a separate option at that point | 16:54:54 |
| emily | since it is doing more system integration than… adding an item to a list | 16:55:11 |
 hexa | nah, nm is just instrumenting the vpn binary | 16:55:39 |
| hexa | I think that's fine | 16:55:46 |
| emily | well I mean vs. pname conditionals | 16:55:55 |
| hexa | install the plugin and you get the executable for free | 16:55:56 |
| emily | "system package gets added based on pname of something in the plugins option of another package's module" is not within expected behaviour for me | 16:56:28 |
| emily | well | 16:56:30 |
| hexa | yeah, this is a minimal approach to make it work | 16:56:32 |
| emily | ok I expect NixOS modules to do arbitrarily horrible things | 16:56:35 |
| hexa | you add the plugin and we make sure it just works | 16:56:49 |
| emily | if adding a package with a certain name disabled the firewall I'd probably just shrug :) | 16:56:51 |
| emily | yeah, but then you switch to your own packaging of networkmanager-openconnect-neo-fork and it stops working suddenly and it's spooky at a distance to find out why | 16:57:18 |
| hexa | we could add a withOpenConnect option to more clearly state what we're doing | 16:57:22 |
| emily | which services.networkmanager.openconnect.enable wouldn't cause because you'd know there's integration going on | 16:57:34 |
| hexa | but I'm not a fan of having too many options for stuff like that | 16:57:44 |
| hexa | hence removing the enableStrongSwan option … that among other things puts the plugin into the plugin list | 16:57:57 |
| emily | options are bad when they don't do actual system integration | 16:57:57 |
| emily | but they're good when they actually are integrating things | 16:58:04 |
| emily | imo | 16:58:08 |
