Emily

``` emily@yuyuko ~> nix hash path /nix/store/xw0462wahwywbl751zdrn5b56m3af4zz-git-2.41.0 sha256-CWP84RaMWzv1WP+UDwQ/f9j+v8y5fEMve8dXb4DEjoc= ``` Seems like file system corruption or something causing the binary to be killed due to a bad hash. I would suggest...

Currently I've just worked around this by `lib.mkBefore`/`lib.mkAfter`ing existing activation scripts in my modules, which seems strictly worse. Unfortunately I don't think there's any way to avoid trusting external modules...

Seems reasonable; how about something like `system.darwin.activationScripts` or `darwin.activationScripts` (or even `darwin.system.activationScripts` if we expect to need to mirror other parts of the options hierarchy for Darwin-specific things)? P.S. I...

(Home Manager uses `home.activation` FWIW; the other existing `system` setting with a NixOS overlap that seems like it could be dangerous is `stateVersion` so maybe that should be `darwin.stateVersion` too?)

I think this would be reasonable but it would be a breaking change that we'd have to handle or warn about somehow. (Error out when the prefix ends with `/bin`?)

+1 for a command for this; maybe `reword!` (`r!` for short) to capture the "don't prompt me for more about this afterwards" intent, and `reword` can default to using the...

I feel that this is often undesirable in NixOS/nix-darwin/home-manager configurations, where you have lots of separate `services.*` and `programs.*` definitions; those are more namespace tags for sets of options than...

AFAIK it's not possible for option documentation to depend on a build (without full-on IFD) so I'm not sure that's practical.

You may also want to consider https://github.com/PyAV-Org/PyAV.

This would make me very happy and secure my wavering Djot fandom. I agree that prefix is better for this and like @matklad's proposed syntax, but if it's considered too...