trcc has quit [Read error: Connection reset by peer]
trcc has joined #nix-darwin
Ericson2314 has joined #nix-darwin
<ejpcmac>
Hi! Is there a programatic way to check if a given derivation is in cache? I want to set `enableParallelBuilding = true;` for an Erlang derivation to speed-up the build, but only if it is not in cache to avoid creating a different derivation, thus forcing the build.
Lisanna has joined #nix-darwin
philr has quit [Quit: WeeChat 2.2]
ldlework has quit [Quit: co'o ro do]
ldlework has joined #nix-darwin
ldlework has quit [Client Quit]
ldlework has joined #nix-darwin
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
hamishmack has quit [Client Quit]
hamishmack has joined #nix-darwin
hamishmack has quit [Client Quit]
hamishmack has joined #nix-darwin
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
carlosdagos has quit [Quit: Connection closed for inactivity]
<ejpcmac>
I’ve tried to put `nixpkgs.config.enableParallelBuilding = true;` in my `home.nix`, and do not patch the derivation to enable the build there but it does not work.
<ejpcmac>
LnL: Ah, you were talking about the true nixpkgs? I’ve seen some discussion about this, and some people seems not to agree about parallel building by default :(
<ejpcmac>
Ah, maybe I could do it for Erlang though.
<ejpcmac>
And update `elixil_1_6` to 1.6.6 in the mean time. Great first contribution for tonight :)
<ejpcmac>
s/elixil/elixir/
<LnL>
ah, too many intermittent build issues?
periklis has joined #nix-darwin
<ejpcmac>
I don’t know, but enabling it globally seems risky apparently. It could break things in an unexpected way. There are so many packages that it is impossible to test all according to some people on a discussion I’ve read. But IMO, I think it would be better if parallel building were the default and problematic packages would set `enableParallelBuilding = false;`. IIRC, this is done this way on FreeBSD.
alexteves has joined #nix-darwin
<LnL>
it depends
<LnL>
in some cases builds start failing frequently when the machine also building other stuff, but usually it's fine
periklis has quit [Read error: Connection reset by peer]
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
trcc has quit [Remote host closed the connection]
chrisaw has joined #nix-darwin
<chrisaw>
Hey folks - really high level question here but how do you tend to manage your custom packages? Overlays? Checkout of the full repo with your changes made?
<chrisaw>
I'm looking to go "all-in" on Nix on macOS incl. GUI apps. With that in mind I'm going to need to create a lot of mac-specific packages but not sure of the best way to go about managing that.
<qyliss^work>
I have a custom packages repository which is itself a package
<qyliss^work>
Then I just import that into my configuration.nix and end up with both `pkgs` and `mypkgs`.
<qyliss^work>
I tried overlays but I found them to be a bit magical - it makes it unclear to me where the code for a package is going to come from.
<chrisaw>
Nice - sounds like exactly what I need!
<LnL>
I use overlays but put all my stuff in a separate attribute set
<chrisaw>
LnL: When you say a separate attribute set - how do you mean? (sorry, still learning Nix and VERY new to nix-darwin)
<chrisaw>
Cool - thanks - more than happy to read and learn! :)
<chrisaw>
LnL: So if I'm understanding this properly - you would install the package with something like: pkgs.lnl.chunkwm ?
<LnL>
yep
<chrisaw>
That sounds great - means I don't have to worry about upstream breaking my custom packages. Nice!
<LnL>
and the super.lnl or {} is there so I extend whatever I added before instead of replacing the entire set
<chrisaw>
Ahh, ok! So that's like a: super.lnl = super.lnl + (new stuff here) ?
<LnL>
yeah essentially
<chrisaw>
Makes sense - going to be a while until I learn the syntax I think but at least I understand the core principles I guess! :)
<LnL>
the self.callPackage isn't required, but I prefer not to use self.package everywhere
<LnL>
and it enables .override
<chrisaw>
Ahh ok, got it!
<chrisaw>
Another thing actually - firefox-bin on Darwin - I see it got fixed upstream in nixpkgs repo but it doesn't list Darwin as a supported platform. I know I can override that but is that quite normal for using Darwin on Mac or should I avoid it?
<chrisaw>
Err *Nix on macOS.
<LnL>
not firefox-bin, only the source build AFIAK
<qyliss^work>
I tried to use GUI applications through Nix on Darwin and it ended up being a nightmare
<qyliss^work>
Things _really_ hate being symlinked
<chrisaw>
Yeah? I wasn't expecting that to be a problem tbh! What kind of issues did you face?
<qyliss^work>
I make an alfred-bin package and it couldn't load some images and stuff from its bundle
<qyliss^work>
It would ask me every time I started if I wanted it to be moved to /Applicatins, even when I said "Don't ask me again"
<qyliss^work>
Homebrew Cask tried to do this for a long time and ended up giving up on it because it just doesn't work properly
<chrisaw>
Ah ok! Probably code to make sure it's not being run from the DMG causing you issues there. Hmm, hadn't thought of that!
<qyliss^work>
For the latter, yeah
<qyliss^work>
But the image loading? No idea.
<chrisaw>
Yeah very strange that one!
<qyliss^work>
This happens in lots and lots of applications too
<chrisaw>
Hmm, that's a shame! I'd usually just run NixOS but it's a work laptop. I have flexibility to do what I want with it but it's one of the new touchbar macbooks and it and Linux don't play nicely together.
<qyliss^work>
I too am using a Mac because work.
<chrisaw>
I wonder if I can do some kind of bind mount between ~/Applications and /Applications or similar. Hmm.
<qyliss^work>
It's not the being in ~/Applications they don't like
<qyliss^work>
If you moved the binaries there they'd be fine
<qyliss^work>
It's that the .app you open is a symlink.
<chrisaw>
Yeah was just thinking that - it's because they're in /nix and symlinked there, good point.
<qyliss^work>
I think
<chrisaw>
I wonder if hard links would make a difference
<qyliss^work>
Hard links would probably work fine
<qyliss^work>
Since a hard link is indistinguishable from the original file
<qyliss^work>
But would break nix
<chrisaw>
Although a .app is a directory and hard links don't work for directories so yeah - non-viable. :(
<qyliss^work>
Oh I didn't know hard links didn't work for directories
<qyliss^work>
I guess that makes sense
<chrisaw>
I'm guessing it wasn't a permissions issue on the image reading thing then?
<chrisaw>
If so - could be relatively simple to just chmod the stuff during package build.
<qyliss^work>
Doubt it? It should all be world-readable.