<prooftechnique>
If I'm getting "file system sandbox blocked stat" for dylibs, is this related to the fixDarwinDylibs thing, or am I hitting something else? Seems to mainly be blowing up on CoreFoundation, which seems to be a bit of sore spot, though I'm not picking up much context from the issue threads I've been finding
<LnL>
the daemon will us a user per build, that has some advantages in terms of cleanup
<dhess>
that's where the module system seems to import lib directly from the Nixpkgs tree rather than using pkgs
<nnkd>
I see, cool thanks for the help!
<LnL>
and again security, running everything as the same user would make it possible for something malicious the change another build that's running
<LnL>
on linux there's some stuff that could be done by dynamically creating user namespaces, but there's not really an equivalent on darwin AFAIK
<LnL>
dhess: yeah there's a difference between lib and pkgs.lib
<nnkd>
I saw an issue saying cgroups could be used to track + cleanup a build's processes, but not really possible to do this without a separate user on darwin
<LnL>
the first on is the vanilla nixpkgs used to evaluate the modules
<LnL>
the second is the nixpkgs imported by the module system itself including overlays, etc.
<LnL>
using pkgs.lib for the modules (eg. mkOption) would result in infinite recursion since nixpkgs.overlays is an option :)
<dhess>
LnL: ok, maybe there's not much value in putting the new types in the overlay in that case. Regardless, I will need to override the lib passed to the module system. I think specialArgs is the way to do that, I'm just not clear on where I would do that
<dhess>
LnL: yes and that is precisely what happens when I try to "with pkgs.lib" in a module :)
<dhess>
I can hack it by referring to pkgs.lib.types.myNewType in the modules, but that's gross
<LnL>
yeah, that's the correct way to use them
<dhess>
with pkgs.lib.types... you mean? or by overriding specialArgs?
<LnL>
no pkgs.lib.foo
<dhess>
oh ok
<dhess>
I think I ran into a problem with that as well. Let me see
<LnL>
I think you can also put them in a module argument
<dhess>
yeah I could do that. Right now I'm just passing in pkgs
<LnL>
{ config = _module.args.foo = ...; }
<LnL>
then you can use { config, lib, foo, ... }: ... in modules