command-not-found fails to suggest correct output to install

[domenkozar]

$ dig
The program ‘dig’ is currently not installed. You can install it by typing:
  nix-env -iA nixos.bind

$ nix-shell -p bind --run "dig"
/tmp/nix-shell-31821-0/rc: line 1: dig: command not found

The problem is that dig binary is in dnsutils output.

Now, this can be fixed two ways:

a) teach command-not-found about outputs

This would possibly need to extend narindex with information from what output are files coming from, so that it can suggest what output to use.

b) restrict stdenv to contain bin/ only in $out or $bin outputs

Pros/Cons

• (b) might mean we have to fix many derivations to comply
• if any of the packages need to exclude enforcement in (b) - for example due to closure size, they would again break command-not-found
• (b) does make things more consistent and predictable for humans

[domenkozar]

nix-index doesn't seem to have this bug as it indexes all files: https://github.com/bennofs/nix-index#a-files-database-for-nixpkgs

[vcunat]

(b) seems too restrictive, for example in this particular dig case. EDIT: I mean, in this case we have the dnsutils alias if you use it directly, but that apparently gets filtered as a duplicate of bind.

[chreekat]

How many commands does this affect besides dig?

Why does bind have split outputs?

[danbst]

still not resolved

[wmertens]

I prefer a), and since nix-index already handles it correctly and also ships a command-not-found replacement, I vote to make nix-index the default.

[stale]

I marked this as stale due to inactivity. → More info

[wmertens]

This would be fixed by #39789

[stale]

I marked this as stale due to inactivity. → More info

[Majiir]

Closing in favor of a more recently active duplicate: #129713