I think I did it with https://github.com/pbek/nixcfg/commit/7cddcb47054b351a484c4959dcf162f9c5c6a2fe!
Thank you for the hint, @vamega!
In my case, I switched "/etc/nixPath"
for "/tmp/nixPath"
because it seems like nix shells modify the /etc
contents based on the shell environment. /etc/nixPath
would disappear and I would be unable to switch shells when using direnv at the same time.
So for anyone else scrolling, my config is:
nix-channel.nix
{ config, pkgs, inputs, ... }: let nixPath = "/tmp/nixPath"; in { systemd.tmpfiles.rules = [ "L+ ${nixPath} - - - - ${pkgs.path}" ]; nix = { nixPath = [ "nixpkgs=${nixPath}" ]; }; }
There is something very strange with your setup then - using /etc/nixPath
absolutely works and the link doesnât disappear.
You can of course put it elsewhere, but /tmp
is a bad idea as it might get automatically cleaned out. If you really donât want /etc
(or canât figure out what makes it disappear), I suggest /run
or /var
instead.
Maybe itâs something to do with direnv? Or something else surrounding that. There was one shell I had where each time I entered direnv, the nixPath would disappear from /etc along with many other folders (the environment variable was still there though), and because of that I couldnât use nix shell
anymore, even via direnv, inside that folder. Worked fine in other folders.
Iâll use /run instead.
That sounds like something strange about the shell, not this approach. Though it seems like youâd have to be doing something pretty cursed in the shell for that to happen⌠Iâm not even sure how a direnv-based shell even could mess with /etc
âŚ
I wasnât doing anything particularly cursed, just importing a couple of packages. Was very confused by it as well, will report back if I find the reason.
Maybe an fhs env? But direnv shouldnât drop into a shell so it could not actually drop into such an environment?
A custom activation script that did something it wasnât supposed to maybe?
If I were you I would definitely focus on finding out why this happens instead of applying workarounds. There is something very wrong with your setup somewhere.
I think I figured it out, itâs because Iâm running vscode inside FHS, so pretty sure itâs expected behavior.
That tracks. The dev shell itself canât possibly do that, but if itâs being run from inside an FHS container it makes perfect sense.