<__monty__>
I've been wondering why nixos modules aren't really a think on darwin. Generating launchd files shouldn't be harder than systemd units right? Is it just a matter of lack of time?
<__monty__>
Maybe I should thing about it first >.<
<gchristensen>
nix-darwin does it
<__monty__>
It does? Why is this the first I'm hearing about this? I'm pretty sure the manual doesn't mention it?
<gchristensen>
I dunno
<gchristensen>
github.com/lnl7/nix-darwin
<LnL>
well it's not an official project
<LnL>
the manual doesn't mention home-manager either
<__monty__>
Oh, maybe my question should've been why there's not a significant amount of services?
<LnL>
ah
<__monty__>
Is there a more fundamental reason than simply lack of time to translate nixos service modules?
<LnL>
well, the way nixos modules work isn't very modular
<gchristensen>
and also probably a "Scratch that itch" thing
<LnL>
so it essentially means everything needs to be reimplemented
<LnL>
and yeah, I don't have the ambition to reimplement and maintain all the nixos services so it's just whatever I use and what people contribute
<__monty__>
So the real way forward would be redoing the nixos modules with enough abstraction, so you can swap out the underlying process manager for example?
<gchristensen>
if not necessarily
<__monty__>
And unless that happens it's basically "reimplement nixos/modules but with a far smaller community?"
<gchristensen>
not sure most of the nixos modules really even seem reasonable to have on macos
<__monty__>
I'd like some backup services for darwin.
<__monty__>
Guess I should write one : ) Don't like the borgbackup module in nixos a ton anyways.
<LnL>
prs welcome :)
<LnL>
urgh, I'm pretty sure all of the leaking memory is in IOHIDDeviceCopyMatchingElements now :/
<LnL>
on the bright side, it's rust now
<gchristensen>
nice
<gchristensen>
what is this?
<LnL>
didn't think it was worth going through ffi, but pleasantly surprised how nice it was
<LnL>
just a small thing to make my capslock key blink
<gchristensen>
oh cool
<gchristensen>
as a notifier?
<LnL>
yeah
<gchristensen>
cool
<gchristensen>
seeing my caps-lock key blink gives me a moment of terror, since it usually means the kernel panicked
<gchristensen>
it would surely get my attention!
<LnL>
lol
<gchristensen>
LnL: did you see the good news? we got a channel
<LnL>
yeah \o/
<LnL>
I wasn't really worried tho, worst case I would have just removed gimp from the constituents
<__monty__>
gchristensen: Gonna kick all the lurkers?
<__monty__>
Whoops, that was for #nixos-chat.
<LnL>
the darwin-tested job is more of a list of things that check if important parts of nixpkgs work, not things that are all that important themselves
<__monty__>
Was it problems with the name again?
hmpffff has joined #nix-darwin
eraserhd2 has quit [Quit: WeeChat 2.8]
eraserhd has joined #nix-darwin
philr has quit [Ping timeout: 264 seconds]
eraserhd has quit [Quit: WeeChat 2.8]
eraserhd has joined #nix-darwin
eraserhd has quit [Quit: WeeChat 2.8]
eraserhd has joined #nix-darwin
<abathur>
the thing I think that would be nice about a more compatible module abstraction is that the implementations would stay in sync
<abathur>
it's easy, especially when you
<abathur>
erg; especially when you're new, to find examples using modules that exist in both nixOS and nix-darwin, but which have subtle config or behavior differences
<abathur>
and not really have the equipment to understand why things aren't working
<abathur>
I saw someone picking at something that seemed like it could pave the way here recently; let me go trawl my gh stars...
<LnL>
alltho that's not the main problem I was referring to
<__monty__>
abathur: Cool! That sounds like what I was thinking.
<LnL>
everything in nixos modules is global
<LnL>
a service module can define etc definitions but also custom activation steps
<LnL>
this makes including a generic module rather dangerous since it could do things that are fine in the context of nixos but brick your macos system
<abathur>
ah, nod
<__monty__>
I assume such a from scratch approach would never suffer that problem though?
<LnL>
right, but just to generalise services you don't have to start from scratch
<LnL>
there are some ideas out there already
<LnL>
but it doesn't really solve the code sharing problem in terms of copy paste
<{^_^}>
#26067 (by copumpkin, 2 years ago, open): Make a service abstraction layer
<abathur>
Something about modules occasionally rubs me the wrong way; I haven't really tried to formulate it.
<abathur>
I think maybe it has to do with how they sometimes take knowledge that's required for actually using a package and disconnect it from the package itself
<abathur>
which has some knock-on effects; it takes more back-tracing to figure out if some example you've found in someone's dotfiles or gist or blogpost is broken because you're an idiot, or because it worked at one point but breaks because the underlying package has drifted
<abathur>
and any time the need doesn't quite fit the module pattern (i.e., I want to run postgres, configured, in a nix-shell, and close it when the shell closes), the knowledge it encodes is only indirectly usable via copypaste
<__monty__>
Oh, that *is* a good point. I have indeed run into wanting a service that only runs for as long as a dev env exists.
<abathur>
I guess interacting with it reminds me of extending or building atop code that feels "mis-abstracted"--in theory you could re-use code, but in practice you end up either copy-pasting it and inheriting the maintenance or spending more time reworking the abstractions than you saved by re-using the code...
<LnL>
right, nix enables installing multiple versions of packages but the modules only work for 1 service, globally
<LnL>
I think things like vim_configurable or withPackages are some good examples of a better direction to go compared to environment.etc
<LnL>
but that's a much more straightforward example ofcourse