Use only 1 channel for my user's `nix-env` and root's `nixos-rebuild`

You are right @danbst, and many development repos that use a default.nix with import <nixpkgs> or alike are broken as well. I’m still not sure how to workaround this while keeping the 3 bullet points I desired in my solution post. In the meantime, at least for projects that use direnv, I have:


In my ~/.config/direnv/direnvrc.

(EDIT) TBH I almost never use nix-build not inside my nixpkgs clone, so it’s not such a big deal for me. However, I think I could do the following instead:

mkdir ~/.nix-defexpr
ln -s /nix/var/nix/profiles/per-user/root/channels/nixos ~/.nix-defexpr/nixpkgs

And set:


But in the meantime I’m more satisfied with the shorter nixos. attribute prefix.

I would rather recommend this:
nix.nixPath = [“nixpkgs=${toString pkgs.path}”];

because it takes less time and space:

$ echo $NIX_PATH

$ time nix-instantiate --eval --expr ‘"${(import {}).path}"’
real 0m1,689s
user 0m0,555s
sys 0m1,125s

nix $ time nix-instantiate --eval --expr ‘"${toString (import {}).path}"’
real 0m0,179s
user 0m0,139s
sys 0m0,034s

Turns out this was a bad idea, please DO NOT use ${toString pkgs.path} but use ${pkgs.path}:
it makes sense only if you’re using a Nixpkgs which is already in the /nix/store/ like myself
(so if you’re using a git clone of Nixpkgs in your home directory,
your Nixpkgs won’t be included in the Nix store),
and you need to hack your way (eg. environment.systemPackages = [pkgs.path];)
to somehow register this path as a dependency of your built system
(without copying it a second time in the /nix/store which would defeat the purpose of the hack),
otherwise that store path can be garbage collected and won’t actually even be sent to the target host
if you’re using nixops.

Sorry for the wrong advice.

PS: lib/tests/release.nix does use ${toString pkgs.path} but also ${pkgs.path} in the same derivation.