<mightybyte>
Ok, I just tried that but that file is not getting executed when I start my shell.
jrolfs has quit [Ping timeout: 240 seconds]
<johnw>
at ~ I have .zshenv
<johnw>
with these contents:
<johnw>
source $HOME/.config/zsh/.zshenv
<johnw>
this file was made by home-manager too
<mightybyte>
Yeah, I have that too.
<LnL>
might be wrong but I don't think ~/.config/zsh is a thing by default
<mightybyte>
But when I open a new iTerm window it doesn't get run.
<johnw>
i have set programs.zsh.dotDir = ".config/zsh";
<mightybyte>
LnL: Yeah, I was trying it in ~ instead of ~/.config/zsh until just now.
<johnw>
mightybyte: is iTerm set to use zsh?
<johnw>
I had to configure iTerm to use this:
<johnw>
/Users/johnw/.nix-profile/bin/zsh -l
<mightybyte>
iTerm is set to use the login shell.
<johnw>
have you use chsh to change your login shell to zsh?
<mightybyte>
echo $SHELL gives me /nix/store/gp7zprn029f6qmxsbhdgmgbn3dlsh5vm-zsh-5.5/bin/zsh
* LnL
has no shell without tmux
<johnw>
mightybyte: even still, I'm not sure that's your true, macOS login shell
<johnw>
not until you use chsh
<mightybyte>
Hmmm
<johnw>
or, tell iTerm to use zsh -l
<LnL>
you'll get that with programs.zsh.enable but it won't chsh automatically
<mightybyte>
I was hoping that nix-darwin would handle that for me.
<mightybyte>
(trying to minimize my reliance on mutable state)
<LnL>
it should, but chsh is annoything because of /etc/shells
<mightybyte>
Ahh, ok.
<mightybyte>
That's too bad.
<mightybyte>
Ok, using zsh -l fixed it.
<mightybyte>
Separate question...how do I fix an "warning: ignoring untrusted substituter" message?
<LnL>
yeah, but I would have to either replace it (scary) or use /bin/zsh but that's a completely different version from what you'd expect (confusing/bad)
<LnL>
mightybyte: is your stateVersion <= 2?
<mightybyte>
Yeah
jrolfs has joined #nix-darwin
<LnL>
read the changelog and bump it or explicilty set nix.version = "2.0"
<mightybyte>
I don't understand that comment. Do I just set stateVersion = 3?
<LnL>
yes, but please read the changelog to understand what that will change :)
<mightybyte>
I did, but I don't understand much more :(
<LnL>
:/
<LnL>
howso?
<mightybyte>
What is nix.package?
<LnL>
the version of nix that will end up in your path and what's used by the daemon service, etc.
<mightybyte>
Maybe I'm just too new at this to have the context, but that changelog comment is pretty much meaningless to me.
<mightybyte>
I have no idea what the implications are.
<LnL>
do you expect nix (and the daemon) to upgrade when you run darwin-rebuild?
<mightybyte>
I guess no
<LnL>
that's the old behaviour, now it will upgrade automatically based on what version is in the nixpkgs you're using
<mightybyte>
Ahhhh
<johnw>
so, I'm getting this again:
<johnw>
/nix/store/8b0gj3bmcy5bh1zcnhn0146199b3m5kb-clang-wrapper-5.0.1/bin/clang++: line 183: /nix/store/p85m242dg1zd85ln3cg0agx0q1n0n6h0-clang-5.0.1/bin/clang++: Argument list too long
<johnw>
this used to happen a while when a stdenv change was made that affected the haskell builds
<johnw>
now it's happening with a c++ application (inkscape)
<johnw>
macOS really constrained link-line length in 10.12
<LnL>
so if you want to keep managing the verison separately like before add nix.package = "/nix/var/nix/profiles/default"; to your configuration
<mightybyte>
LnL: Ok. So this is going to be the behavior for all stateVersion > 2?
<mightybyte>
What's the most recent stateVersion?
<LnL>
but using a profile means nix-darwin can't figure out what the actual version you're using is so you might need to also specify that to make in generate a correct config
<LnL>
the current is 3 I think
<mightybyte>
Ok
<LnL>
I handle stateVersion differently from nixos because I think this makes more sense
<LnL>
every incompatibility bumps the number and the changelog includes instructions on how to handle each step
<LnL>
that way you can decide what you want to keep
<mightybyte>
Great, good to know.
<mightybyte>
It wasn't obvious to me from this changelog entry what stateVersion should be changed to.