Open ncfavier opened 1 year ago
I am not sure if the metadata that nix-index processes includes the destination of the symlink. But if that's the case I agree that we should try to resolve symlinks by default (maybe with an option to disable this behaviour)
It is. If we resolve symlinks then a question arises: should a path be marked s
when its last component is a symlink, or when any component is?
Just to add another example, this also hurts node packages, where $out/bin
points to lib/node_modules/.bin/
:
$ which pnpm
/nix/store/jxyv7qildiy960h194h4ca3wharbbpks-pnpm-8.15.3/bin/pnpm
$ ls -al /nix/store/jxyv7qildiy960h194h4ca3wharbbpks-pnpm-8.15.3/bin
lrwxrwxrwx 1 root root 21 janv. 1 1970 /nix/store/jxyv7qildiy960h194h4ca3wharbbpks-pnpm-8.15.3/bin -> lib/node_modules/.bin
$ nix-locate bin/pnpm
nodePackages.pnpm.out 637 x /nix/store/jxyv7qildiy960h194h4ca3wharbbpks-pnpm-8.15.3/lib/node_modules/.bin/pnpm
nodePackages.pnpm.out 1,047 x /nix/store/jxyv7qildiy960h194h4ca3wharbbpks-pnpm-8.15.3/lib/node_modules/pnpm/bin/pnpm.cjs
[… other entries unrelated to nodePackages.pnpm …]
As a consequence, the nix-index
module fails to propose the right package:
$ pnpm
The program 'pnpm' is currently not installed. It is provided by
several packages. You can install it by typing one of the following:
nix profile install nixpkgs#corepack_18.out
nix profile install nixpkgs#corepack.out
nix profile install nixpkgs#corepack_21.out
Or run it once with:
nix shell nixpkgs#corepack_18.out -c pnpm ...
nix shell nixpkgs#corepack.out -c pnpm ...
nix shell nixpkgs#corepack_21.out -c pnpm ...
The
go
package in nixpkgs looks like this:When searching for
/bin/go
, the only returned entry forgo.out
isThus adding
--top-level
does not returngo.out
.I think the expected behaviour would be for nix-index to index all paths, even with possible duplicates. In this case, both
/bin/go
and/share/go/bin/go
should be returned.