<__monty__>
netixx Good, now you should be able to use `<nixpkgs>` to refer to root's nixos channel. (Might want to use `nixos=` instead of `nixpkgs=` it's just a name.)
<__monty__>
If you want access to all of roots channels and the permissions work out you could just have that last path and remove the first and nixpkgs=.
<netixx>
ok so by default the `pkgs` in ` { config, pkgs, ... }:` in home.nix will be `<nixpkgs>` ?
<__monty__>
Not sure how HM passes that argument. Try and see?
<mankyKitty>
K
<__monty__>
Easiest way to verify is probably to remove all your user's channels. If HM and nix still work you're probably using root's : )
<netixx>
thank you for you help, I will investigate with different channel configuration
<__monty__>
Ah, because it uses <nixpkgs> you'll have to add a nixpkgs= to your NIX_PATH.
<__monty__>
It's possible there's a configuration option though.
<netixx>
my knowledge of nix/os has been tested... I guess it not clear yet the link between channels, NIX_PATH etc...
<netixx>
But It does not seem to be a home-manager related problem then...
<__monty__>
Btw, a different approach would be to have root choose a nixpkgs pin and then just import that.
<__monty__>
Yeah, it's a bit of a weird setup you want.
<__monty__>
When nix encounters a name in <>'s it goes looking in NIX_PATH for that name. I think it does so depth first though. So as long as you have your user's channel path at the front you'll always end up using your user's nixpkgs channel.
<netixx>
ok , the way I understand it, If I have a user user channel named `nixpgks`, then it will use this, otherwise, is will use the path referenced by `nixpkgs=` (which I can override in my nix-path)
<__monty__>
netixx: Yep.
netixx has quit [Remote host closed the connection]
johnw has quit [Remote host closed the connection]
mcwitt has quit [Remote host closed the connection]
mcwitt has joined #home-manager
mcwitt has left #home-manager [#home-manager]
mcwitt has joined #home-manager
<mcwitt>
Ok, I discovered by looking at `/var/log/lightdm/lightdm.log` that lightdm was trying to start a nonexistent session "none+xmonad". This is weird because this default was removed from my `configuration.nix`; it almost seems like nixos-rebuild didn't clean up some stale config. But setting `services.xserver.desktopManager.xterm.enable = true` in `configuration.nix` fixed the issue.
<srk>
iirc it was changed to disabled by default few months ago
<srk>
sorry, didn't notice your earlier question
<energizer>
i'm using the HM nixos module, and somehow an old version of my config is being invoked for `nixos-rebuild switch`. it's trying to install a file and says "/home/energizer/.config/Code/User/settings.json is in the way". but nixos-option home-manager.users.energizer.xdg.configFile doesn't list that file. what could be going wrong?
cp9 has quit [Remote host closed the connection]
SarahStep has joined #home-manager
SarahStep has quit [Client Quit]
<energizer>
oh it's under vscode.userSettings, duh
<energizer>
i would like to be able to 1) edit my vscode user settings in the vscode gui 2) keep settings.json in version control 3) have HM install the file. Is it possible to have HM install a link to a mutable file?
<__monty__>
Yep.
<__monty__>
You'll want an activationBlock I think it's called.
<rycee>
An alternative is to use something like `xdg.configFile."Code/User/settings.json".source = runCommandLocal "settings.json" {} ''ln -s "/home/energizer/path/to/file" $out''`
<energizer>
rycee: what is the difference between the two?
<rycee>
I'm intending to add some function `mkOutOfStoreSymlink` that provides a more convenient way to do this.
<energizer>
cool
<rycee>
energizer: In practice no major difference. The only difference I can think of is that the `xdg.configFile` way will remove the link if you remove the configuration.
<rycee>
The activation script way is more low-level.