Do flakes also set the system channel?

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.