modules/nixos: implement session variables

[nezia1]

This pull request adds handling of NixOS session variables through environment.d. However, I had questions about a few design decisions that I made:

1. One of the shortcomings of NixOS when it comes to managing environment variables with environment.d is that if said variable is already defined in environment.variables, the user variables defined will not take precedence over the NixOS option. One of the solutions I've found was to explicitely unset it in environment.extraInit, but the issue with that is that it unsets it for the entire system, which is a no-go for a home management solution. I did add a forceOverride option in environment.nix as draft, but I'd like to get input on that.

2. Is systemd ultimately even what we want to manage session variables? I found it extremely convenient, but it makes for a. a solution tied to systemd in general, which is probably fine for NixOS since it heavily depends on systemd and b. not portable to other systems.

I'd also like to gather input on the code, ie. if I misplaced some options that should go into common.nix.

[nezia1]

I have additionally added a no systemd version, under this branch. This is a simpler implementation that just creates ~/.profile, and seemed to work just fine. Keep in mind that I am using greetd, which does source ~/.profile, so this might not work on other display managers.

I have also tested this with zsh and fish, and it seemed to set the variables just fine.

[NotAShelf]

Given this is an addition to the NixOS module, and that NixOS does in fact use systemd. It feels like a safer bet to expect ~/.config/environment.d rather than ~/.profile. Shame we cannot do this with PAM directly, but @eclairevoyant and I have agreed that non-systemd support within the NixOS module is not quite a priority.

[eclairevoyant]

The envvar shadowing is unfortunate, but I can't think of a better solution at this time for that.

[nezia1]

The envvar shadowing is unfortunate, but I can't think of a better solution at this time for that.

It definitely is, I'm not sure how else we could do it. So far this seems to be the only solution if we do want to use environment.d. I think putting it under a mkEnableOption is probably the best we could do. Perhaps I should document it better, and say that this will in fact override everything globally even though it might be only one user that has a conflicting variable?

[nezia1]

The concatStringsSep was previously not turning values inside of the list into strings. Fixed

[nezia1]

@eclairevoyant This should be done. What do you think? Not too sure about the type handling in toEnv, but as we only have int path str we should be okay.

[nezia1]

The suggestion @NotAShelf mentioned (making sure the file is sourced only once per interactive non-login child shells) has been implemented. Let me know if there is anything that doesn't look right