<eraserhd>
Does anyone have a good solution for making modules that behave differently on Darwin and NixOS? Background: stdenv.isDarwin is often too late, as I can't make a config that sets nix-darwin options, so I've resorted to (builtins.hasAttr "launchd" options), which is kind of yucky.
<eraserhd>
I guess the best way is really to make separate modules for each with a common interface, and include the right ones at the top level?
<LnL>
yeah, but the module system isn't very composable in this way
<eraserhd>
Too bad I don't quite understand the module code. It seems like it should be possible to pass down a parameter?
<eraserhd>
I guess it would have to be done prior to the machine config, though.
* infinisil
understands the module code
<eraserhd>
infinisil: nice :)
<infinisil>
Hmm
<infinisil>
So you want to change module behavior depending on whether the final thing gets deployed to macos or linux?
<infinisil>
Or maybe just depending on whether you evaluate on macos or linux?
<infinisil>
Because the latter could be done with builtins.currentSystem
<eraserhd>
Yeah. I mean, I'm aiming for the same effect. This is mostly my dev environment, and I address OS differences.
<eraserhd>
hmm
<eraserhd>
ok, that is definitely eager enough :D
<infinisil>
eraserhd: What's the problem with using `config = if pkgs.stdenv.isDarwin then ... else ...;` btw?
<infinisil>
Or is that not what you meant?
<eraserhd>
infinisil: if you do this and set a nix-darwin-only option, when you try to build the same config on NixOS it fails saying the option doesn't exist.
<infinisil>
Even though pkgs.stdenv.isDarwin is false in that case?
<eraserhd>
Yes.
<infinisil>
That's weird..
<infinisil>
I think this would be a problem if `mkIf pkgs.stdenv.isDarwin` is used, but not with the builtin if
<eraserhd>
Ohh.. I misread.
<infinisil>
Though I think what I showed above will give infinite recursion actually
<eraserhd>
I'm not 100% sure I tried with plain if, but I definitely encountered infinite recursion when trying to figure out different options, and I feel like that was probably one of them.
<infinisil>
Yeah
<infinisil>
Hmm
<eraserhd>
I guess I can't imagine I wouldn't have tried it after mkIf failed and before using hasAttr.
<infinisil>
So the infinite recursion comes from evaluating pkgs, which depends on config.nixpkgs.overlays (among others)
<infinisil>
And to evaluate config.nixpkgs.overlays it needs to inspect all config assignments
<infinisil>
But the config assignment above depends on pkgs -> inf rec
<infinisil>
The reason `options ? launchd` works is because evaluating options doesn't evaluate config
<infinisil>
(usually at least)
<eraserhd>
in theory, currentSystem isn't necessarily the target system, right? I can't imagine when I wouldn't have them equal tho...
<infinisil>
Indeed they don't have to be the same. currentSystem is just on which system you evaluate it. An example where it wouldn't be the target system is when you build a nix-darwin config on linux (via a remote builder)
<infinisil>
This would evaluate the Nix code on Linux, instantiate the derivations, send the instructions for building them to the remote darwin builder, which then sends the results back
<infinisil>
eraserhd: I think the best solution is to just cleanly separate NixOS/nix-darwin configs
<infinisil>
At least the modules that can't be shared
<eraserhd>
I'm concluding that is preferred, but it isn't always sufficient. I think I'm going to make a simple module that checks options ? launchd and exports config.system of "nix-darwin" or "NixOS".
<eraserhd>
Which is hides the yucky bit, which I'm ok with.
<infinisil>
eraserhd: Well that will give you inf rec again if you try to use it like `config = if config.system == "nix-darwin" then ...`
<infinisil>
Same reason as explained above
<eraserhd>
oh drat
<infinisil>
If you do `options.system = mkOption { default = "nix-darwin"; }` though, you can use it with `config = if options.system.default == "nix-darwin" then ...`
<infinisil>
Or `default = options ? launchd` should work too there