Package Manager Integrations

Package manager integration is added along with v0.5.15. However, not all package managers are supported yet.

• Some package managers allow searching for a package containing an executable. In this case, we can retrieve the package list directly
  • E.g.: pacman -Fq /usr/bin/executable
• Package managers of some distributions that do not provide such functionality will likely ship with a command_not_found handle by default which suggest packages to install. We can use such output to generate a suggestion

Relevant file.

Progress:

• [x] Pacman (pkgfile, pacman -Fq)
• [x] APT / Snap / pkg (apt-file, command-not-found)
• [x] DNF (dnf provides)
• [x] Portage (e-file)
• [x] guix (guix locate)
• [x] nix (nix-locate 'bin/{}')
• [x] YUM (yum provides)
• [ ] Zypper
• [ ] Slackpkg
• [ ] ...

@SigmaSquadron iirc, nixos comes with a command_not_found hook that we can use. Could you take it a look when you have some spare time?

The default command_not_found isn't extensible. Programs like nix-locate opt to make their own implementation and replace the default command_not_found implementation.

To query certain files inside Nix Store paths, one could leverage nix-index. (which already does this, although it's extremely slow, since we have over 120k packages.)

although it's extremely slow

I think they are doing some fuzzy searching and apparently not a HashMap based index.

Anyway, it's an optional feature we can enable if nix-locate is installed and just skip if not.

@SigmaSquadron Does this work? https://github.com/iffse/pay-respects/blob/bf096d2b7506c8af6e0af34492391afe842f4faa/src/system.rs#L78-L87

The command syntax should be just nix-locate {}, as /usr/bin won't be a valid path. Not all binary outputs are named out. Sometimes they're named bin, but really they can just be arbitrarily named. What matters is that binaries will always be inside a folder named bin/ on the root of the output.

I should also note that nix-locate takes 1-2s to run on a good day. Expect pay-requests to be slowed down accordingly.

I should also note that nix-locate takes 1-2s to run on a good day. Expect pay-requests to be slowed down accordingly.

pay-respects itself retrieves the suggestion in less than 50ms, so the experience should be the same as the command_not_found handle of nix-index itself.

At least I would take more than 2 second to type nix-env -iA package_name!

as /usr/bin won't be a valid path.

Strange, official doc show an example with nix-locate 'bin/hello'.

I think the package can get installed like nix-env -iA nixpkgs.executable.out?

https://github.com/iffse/pay-respects/blob/06bd676618087f4a5ea680223ce1f9a8725ec233/src/system.rs#L87-L99 https://github.com/iffse/pay-respects/blob/06bd676618087f4a5ea680223ce1f9a8725ec233/src/system.rs#L129

Strange, official doc show an example with nix-locate 'bin/hello'.

bin/hello is valid. /bin/hello or /usr/bin/hello is not.

All right, current code should be good then

I think the package can get installed like nix-env -iA nixpkgs.executable.out?

You'd want to avoid installing packages, I think. Consider using nix-shell -p <output name> --command <executable name> Most of the time, <output name> == <executable name>, but this isn't always the case.

Consider the following nix-locate output:

coreutils.out   0 s  /nix/store/k48bha2fjqzarg52picsdfwlqx75aqbb-coreutils-9.5/bin/cat

It should suggest the command nix-shell --packages coreutils --command cat

You'd want to avoid installing packages

Gets a bit tricky as nix-shell creates a temporary $PATH, and it won't affect host process/shells.

The use case should be that the user is familiar with a command but happens to not have it installed (new machine, for example), so I think we can keep it simple to install directly.

Then avoid using nix-env, and use the newer nix profile install nixpkgs#hello.

Should be good now. Thanks!

https://github.com/iffse/pay-respects/blob/1c9302ea94323f879f4c605a236af97412719b16/src/system.rs#L134

Would like to install this with brew on my mac, thanks

Would like to install this with brew on my mac, thanks

@rexkyng Saw you already created a brew repo for pay-respects. I'll add it to the installation methods, thanks!

+1 for brew, as in auto-installing stuff if it's missing. not being able to install pay-respects via brew

@ALameLlama brew doesn't seem to have the functionality to search for binaries

You can install via brew with brew install timescam/homebrew-tap/pay-respects (3rd party repository)

I packaged this program for Guix but it seems that Guix can't search for binaries :/

@gs-101 this https://unix.stackexchange.com/a/780421?

@gs-101 this https://unix.stackexchange.com/a/780421?

Oh, nice! I was looking into only guix package...

Then avoid using nix-env, and use the newer nix profile install nixpkgs#hello.

nix-env and nix profile both are still in use. I suggest using comma instead.

, cowsay Hello

Are you aware that comma is just a wrapper for nix-locate and nix shell? It wouldn't serve any purpose here.

Current code permanently install the package using nix profile install nixpkgs#{}. Shouldn't it be temporary?

You should take a look at the comment directly above the one you quoted :p https://github.com/iffse/pay-respects/issues/17#issuecomment-2525340324

It really surprised me when pay-respects installed a Nix package straight to my system profile. Personally I would never use nix-env or nix profile as it really defeats the purpose of using a nix-managed environment.

As of 2021, NixOS' default command-not-found implementation exclusively recommends nix-shell. While not all Nix users are NixOS users, I think the reasoning here stands:

The goal [...] is to steer beginners away from nix-env for their "I want to use this bin" needs, and towards the much "safer" nix-shell. If you already know what you're doing, then I doubt you were looking at command-not-found's output anyway.

Perhaps there is an elegant way for the user to specify their preference for nix-shell over nix profile, or vice-versa?

If you already know what you're doing, then I doubt you were looking at command-not-found's output anyway.

This is supposed to be the case where "you already know what you're doing". I hardly doubt if you typed a command straight away that you don't know what you are doing.

It appears, though, we could add a way to use nix shell like nix shell nixpkgs#program --command sh -c "<original command> && <shell>". It's quite dirty, as you will be running your shell inside sh inside pay-respect inside your original shell.

You can now use nix shell by setting installation method to Shell

Awesome! Is this configurable through the system-wide path in /etc/xdg/pay-respects or only through the user configuration paths?