| 29 Jun 2025 |
 emily | it seems like most of it comes for free just by patching their main function | 16:50:47 |
 hexa | * but in general more stuff should be looked up from the path at runtime | 16:50:52 |
| emily | but the firewall stuff, no | 16:50:56 |
| hexa | like … when firewalling is enabled you have the ipt or nft executables in the path already | 16:51:43 |
| hexa | so just pick those | 16:51:45 |
| emily | I agree that late-binding is not the devil fwiw | 16:52:36 |
| emily | but that's an argument to have with upstream re: NFT_PATH | 16:53:00 |
| emily | and in the meantime it doesn't matter | 16:53:10 |
| emily | (but I think we agree on this) | 16:53:12 |
| hexa |
nmcli or nmtui tools pull in the NetworkManager library and use those functions to search for binaries. If you then, for example, add an openconnect VPN and try to connect, they will search for the openconnect binary in their PATH as well.
| 16:54:03 |
| hexa | I added openconnect as a system package because of that remark | 16:54:16 |
| 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 |
