Internal detection of `nix` binary path is inconsistent after Nix 2.29

[getchoo]

Note

This is a copy of DeterminateSystems#1672

Since the component split of Nix 2.29, /nix/store may now contain multiple paths matching the nix-* glob used here:

experimental-nix-installer/src/action/common/configure_nix.rs

Line 84 in 20be610

let nix_pkg_glob = format!("{}/nix-*/store/*-nix-*.*.*", unpacked_path.display());

This creates issues when the first result is a component's store path (like nix-main) that does not contain a binary, which can happen in release tarballs like the Linux one from this upstream CI run

Thankfully this is currently limited to users manually setting --nix-package-url - as it doesn't seem this case has ever hit the release tarballs bundled with the installer - but I wouldn't be surprised if this would affect development later down the line...

I discovered this by implementing this installer into Nix's dogfed installer tests in NixOS/nix#14002

[Mic92]

We can probably use the nix-cli pname for matching more precisely?

[adamcstephens]

We can probably use the nix-cli pname for matching more precisely?

The installer is using this nix binary to run commands with nix internally. Meaning it needs a nix, which won't always be available, and all it has is a tarball with store paths. Given that, I think #48 will likely fix the issue.