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:
(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:
$ time nix-instantiate --eval --expr ‘"${(import {}).path}"’
“/nix/store/dw3c31d3cgr79la1mby3h1ygk05wkzxx-3c7fs73pbrgg9lw9dj8dzvg0zw0wrlsm-nixpkgs-patched”
real 0m1,689s
user 0m0,555s
sys 0m1,125s
nix $ time nix-instantiate --eval --expr ‘"${toString (import {}).path}"’
“/nix/store/3c7fs73pbrgg9lw9dj8dzvg0zw0wrlsm-nixpkgs-patched”
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.