`vmTools.vmRunCommand` and `$stdenv`

Help
1

As of https://github.com/NixOS/nixpkgs/commit/26eba25577388072ba13b1682860fe872ba39942, the script generated by vmTools.vmRunCommand expects the shell variable $stdenv to be set in its environment. This has broken disko’s use of this function: https://github.com/nix-community/disko/issues/1027

disko is clearly using vmRunCommand outside of the norm – it’s using it in order to generate a script that’s meant to be run outside of the Nix builder. There is a wrapper around the script generated by vmRunCommand, so there is a place to set stdenv, but … I can’t figure out what sets stdenv in more normal uses of vmRunCommand, either. All the uses of that variable within vmTools just take it for granted that it’ll be ambiently available, and the code within nixpkgs/pkgs/stdenv is too complicated for my current level of understanding of the Nix language and the structure of nixpkgs (in both cases this is “enough to get myself in trouble, not enough to get back out again” :stuck_out_tongue_winking_eye: )

Digging through the store, I’m pretty sure stdenv is supposed to be set to something like /nix/store/lgydi1gl5wqcw6k4gyjbaxx7b40zxrsp-stdenv-linux, but that doesn’t tell me how to poke the correct version of that store path into a script.

Any advice?

2

Wasn’t that fixed by disk-image: Fix compatibility with nixpkgs unstable by iFreilicht · Pull Request #907 · nix-community/disko · GitHub?

3

No. That change alters the preVM script, but the vm-run script only invokes the preVM script after doing source $stdenv/setup, so that change can’t have had any effect on this specific problem.

$ head -10 /nix/store/f04j2m3wh3sdl6haidbilmfg9n2z1k4x-vm-run
/nix/store/cg09nslw3w6afyynjw484b86d47ic1cb-coreutils-9.7/bin/mkdir xchg
export > xchg/saved-env

if [ -f "${NIX_ATTRS_SH_FILE-}" ]; then
  /nix/store/cg09nslw3w6afyynjw484b86d47ic1cb-coreutils-9.7/bin/cp $NIX_ATTRS_JSON_FILE $NIX_ATTRS_SH_FILE xchg
  source "$NIX_ATTRS_SH_FILE"
fi
source $stdenv/setup

eval "$preVM"

Note also that it’s the vm-run script that creates saved-env; $stdenv, and perhaps other variables I haven’t tripped over yet, are assumed already to be set in the environment at the point of the export command.