rycee changed the topic of #home-manager to: Support and discussion around the Home Manager project (https://github.com/rycee/home-manager) | Logs: https://logs.nix.samueldr.com/home-manager
mexisme has quit [Ping timeout: 250 seconds]
mexisme has joined #home-manager
mexisme has quit [Ping timeout: 264 seconds]
pie_ has joined #home-manager
ardumont has quit [Ping timeout: 250 seconds]
ardumont has joined #home-manager
mexisme has joined #home-manager
__monty__ has joined #home-manager
mexisme has quit [Ping timeout: 264 seconds]
klntsky has quit [Read error: Connection reset by peer]
klntsky has joined #home-manager
__monty__ has quit [Ping timeout: 244 seconds]
__monty__ has joined #home-manager
<__monty__> Trying to use firefox-bin-unwrapped as the unwrapped package for home-manager's programs.firefox. The build fails with `cannot find executable file /nix/store/blah-firefox-bin-unwrapped/bin/firefox-release-bin-unwrapped`, that seems like a suspicious executable name.
<__monty__> Is this a home-manager specific issue?
hmpffff has joined #home-manager
hmpffff has quit [Client Quit]
hmpffff has joined #home-manager
<rycee> Yeah, unfortunately it is. The package given to Home Manager should be a wrapped one but unfortunately Nixpkgs 19.03 doesn't allow the Firefox configuration to be overridden so HM was limited to working with the unwrapped package.
<rycee> The unstable branch should now be able to work with wrapped Firefox packages since I fixed Nixpkgs. I haven't updated HM yet, though.
<__monty__> rycee: Ah, would you recommend I drop the hm module for now and just go with firefox-bin?
<rycee> Yeah, I'm afraid so unless you want to cherry pick some commits into your Nixpkgs and Home Manager :-)
<rycee> But probably easier to wait until 19.09 has been released.
<__monty__> Ok, thanks.
hmpffff has quit [Quit: Bye…]
hmpffff has joined #home-manager
<__monty__> Is there a way to have home-manager provide a file without making it readonly? Merely a symlink maybe?
<rycee> Not directly. My usual suggestion is to create an activation block that puts the file in place.
<rycee> Note, the hack with `home.file.".spacemacs".source` no longer works but the `home.activation.linkMyStuff` thing should work.
<__monty__> rycee: Hmm, home-manager complains about the `dag` variable. And I can't find anything in the manual. Not even home.activation actually. What is "dag.entryAfter [ "writeBoundary" ]"?
__monty__ has quit [Ping timeout: 245 seconds]
<rycee> dag = config.lib.dag;
<rycee> So `config.lib.dag.entryAfter [ "writeBoundary" ]` should work.
<rycee> (assuming your module takes config from the argument attribute set)
__monty__ has joined #home-manager
<__monty__> rycee: And another question. I'm trying to link stuff to ~/Applications like so: https://github.com/toonn/nix-config/blob/master/home/home.nix#L48 and Applications is included in /nix/store/*-home-manager-path but it's not in .nix-profile and certainly not in my ~, any idea what's going wrong there?
<__monty__> Btw, I got disconnected if anyone happens to have answered my last question?
<rycee> Hmm.
<rycee> Curious that it's not in ~/.nix-profile.
<rycee> So for example inkscape is not at all in `~/.nix-profile`?
<__monty__> Better yet, "Applications" is not at all in ~/.nix-profile.
<rycee> Hmm, is the Applications directory in a separate output?
<rycee> Seems very odd that it wouldn't show up at all.
<rycee> Does it show up if you install it directly? Like with `nix-env -f '<nixpkgs>' -iA inkscape`.
mexisme has joined #home-manager
<__monty__> rycee: Seperate output? It's in the -App buildenv. And also in /nix/store/*-wire-desktop.../Applications
<__monty__> For example.
<__monty__> Uhm, not on the machine currently so I can't try the nix-env command rn.
sheelx has joined #home-manager
<rycee> Yeah, seems quite peculiar. HM doesn't really do much with the things inside home.packages. It just wraps them up in a buildEnv and installs that using nix-env.
<rycee> So I'm curious what happens if you just do the nix-env directly…
<__monty__> And nesting of buildEnv's is fine?
<rycee> Yeah, that shouldn't be a problem.
<__monty__> What I wonder is why it *is* in /nix/store/*-home-manager-path but not .nix-profile or anything.
<__monty__> rycee: Did you answer the dag question?
<rycee> Basically, try `config.lib.dag.entryAfter [ "writeBoundary" ]`
<__monty__> rycee: Ah, thanks. I guess I missed that in the disconnect. Really appreciate the help btw.
<rycee> HM literally does `nix-env -i /nix/store/…-home-manager-path` when installing the packages to your user profile so I can't say how it's possible that things are lost in that step.
<rycee> Does the Applications directory show up when you run `ls /nix/var/nix/profiles/per-user/$USER/home-manager/home-path`?
<__monty__> I can check in 30min or so.
<rycee> Alright. I'll be around for an hour or so longer :-)
<__monty__> rycee: Hmm, I'm switching to home.activation from home.files. Do I simply rm the ro files? The linking fails because they're still in place.
<rycee> Ya, that's fine to do.
<rycee> Or change "writeBoundary" to "linkGeneration", then they'll be removed automatically.
<__monty__> What are these actually? I feel like I should understand them before blindly putting them in my home.nix
<rycee> They're just names of "activation blocks", basically pieces of code that goes in the activation script.
<rycee> For example `/nix/var/nix/profiles/per-user/$USER/home-manager/activate`
<__monty__> And why would the linkGeneration block automatically overwrite even ro files?
<rycee> The writeBoundary one is a bit special. Any code that changes anything on disk goes after this block.
<__monty__> Why was the first suggestion writeBoundary? Is it safer or something?
<rycee> The linkGeneration one is the code that creates the symlink in the first place, it also removes symlinks that no longer have a matching `home.file` entry.
<rycee> Whether you choose writeBoundary or linkGeneration doesn't matter once the ro link has been removed.
<rycee> I would suggest simply removing them manually and then leaving the dependency on writeBoundary.
sheelx has quit [Ping timeout: 272 seconds]
<__monty__> I don't suppose there's a way to specify XDG_CONFIG_HOME rather than hardcoding $HOME/.config?
<rycee> Yeah, that should work.
<__monty__> It complains about XDG_CONFIG_HOME being unbound though.
<rycee> Then you haven't set the XDG_CONFIG_HOME variable I guess :-)
<rycee> Alternatively, you can use ${config.xdg.configHome}.
<__monty__> Ah, and it doesn't get set to a default? I thought the point was that anything could use the var and get a sensible location?
<rycee> No, it's voluntary to set it.
<rycee> People often use `${XDG_CONFIG_HOME:-$HOME/.config}`
<rycee> So that `~/.config` is used if `XDG_CONFIG_HOME` is unset.
<__monty__> Another problems solved : )
<__monty__> rycee++
mexisme has quit [Ping timeout: 252 seconds]
<rycee> If you want to use a non-standard location for XDG_CONFIG_HOME or any of the other XDG variables then I suggest setting `xdg.enable = true;` and `xdg.configHome = "${config.home.homeDirectory}/path/to/your/config";`
<__monty__> I don't. I just like the idea of not hardcoding it in case I ever want to change it.
<rycee> Ok :-)
mexisme has joined #home-manager
mexisme has quit [Ping timeout: 264 seconds]
<__monty__> Booting the problematic machine now.
<__monty__> rycee: Ok, so Applications is in /nix/var/nix/.../home-path.
<__monty__> rycee: And yep, even without the extra buildenv wrapping apps end up in .nix-profile/Applications
<rycee> Hmm, but that sounds good?
<__monty__> rycee: Not really. Don't want to nix-env -iA all the apps.
<rycee> Ah, right. This is when you install through nix-env, not home manager.
<rycee> If you do `nix-env -i /nix/var/nix/profiles/per-user/$USER/home-manager/home-path` does Applications show up in ~/.nix-profile?
<__monty__> Yes.
<__monty__> So somehow what should be happening is not happening?
<__monty__> Could this be because I'm using the nix-darwin module?
<rycee> Ah!
<rycee> Do you have `home-manager.useUserPackages` set to `true`?
<__monty__> I do.
<rycee> Yeah, then the packages set in home.packages won't show up in ~/.nix-profile at all I think.
<rycee> Not sure where they end up on nix-darwin :-)
<__monty__> Ah, they end up in /etc/profiles apparently.
<__monty__> Hmm, or they're supposed to? That doesn't have Applications.
<rycee> Found in the nix-darwin code that they are installed to `/etc/profiles/per-user/$USER`
<__monty__> Yeah but that only has bin, etc, info and share for me.
<__monty__> No Applications and no Library.
<__monty__> Oh, Library *does* end up in .nix-profile btw.
<__monty__> Hmm, no, only contains a nix-daemon plist.
<__monty__> rycee: Let's continue this tomorrow? I'll have a thorougher look in the actual home-manager/nix-darwin code, see if I can't spot the funny business.
<rycee> There are some issues open related to these things, like https://github.com/LnL7/nix-darwin/issues/139
<__monty__> Would you recommend switching to your nur import?
<rycee> I don't know if #nix-darwin could help better. I have a very fuzzy understanding of macOS.
<rycee> If you already have NUR installed then you could give it a try. It shouldn't make a difference for this issue, though.
<rycee> I'll head to bed. See ya!
<__monty__> They basically said "nix-darwin already links applications" "oh, home-manager doesn't do the same magic look into buildEnv's pathsToLink."
<__monty__> nn, rycee
__monty__ has quit [Quit: leaving]
sheelx has joined #home-manager
hmpffff has quit [Quit: nchrrrr…]
sheelx has quit [Ping timeout: 272 seconds]
sheelx has joined #home-manager
sheelx has quit [Ping timeout: 246 seconds]