[Feature] Add "homepage" field

[kevb1973]

One very useful feature I use with nh search is the homepage field.
It's a nice way to quickly access the project's homepage/github repo to get more information on the project.
Github link to the package.nix would be a nice addition as well.

Nice project!

[OleMussmann]

Thanks for the initiative, @kevb1973 . nh search is currently broken in nixpkgs (see further down), but I found a screenshot on the project's website that probably shows what you mean:

It is similar to the existing multi-line mode below, though nh search is much more detailed.

I'm hesitant to make that a default, since it significantly lowers the information density on the screen. However, I'd love to have this information available.

The implementation challenges are:

1. Where to get this information from?
2. How to show it to the user?

Information Source

nps currently gets its package information from either nix search nixpkgs ^ or nix-env -qaP --description, which does not contain the homepage or package.nix source information.

Recently I learned about two other programs that search nix packages. One is nh search that you mentioned, the other one is nix-search-cli. If I had known about those two years ago, I would have not written nps. 😅 Oh well, choice is good.

The two other programs pull their information out of an elasticsearch database with hard-coded credentials. While the credentials are the same, the API URLs differ:

• https://search.nixos.org/backend/latest-44-{channel}/_search and
• https://nixos-search-7-1733963800.us-east-1.bonsaisearch.net:443/%s/_search

Both look rather brittle to me. In fact, nh search broke because of outdated credentials. Reading the issue, I assume the URL changed. There does not seem to be a (long-term) stable API that one can query.

On the flip side, nix search tweaked its syntax a while ago and nps broke because of that. There is really nothing stable out there to query. Fun times.

Interface

Assuming nps would switch to the elasticsearch API as its information source, what would the output look like? For the default, I would like to keep it as close to what we have now as possible. The extra information could then be either baked in the above shown multi-line output (maybe the option would need a new name then?), or it could be its own flag.

---

Have I missed something? Or do you maybe have other ideas that I haven't discussed yet? What would your preferred implementation look like?

[kevb1973]

I had the same issue with nh, but the latest version seems to be fixed.

Your project still as merit, as it keeps the database local and doesn't require a constant internet connection. It's also super fast, and the one line per package output could be useful for scripting. For example, I have kitty terminal keyboard shortcuts that will bring up hints for packages in the search output to quickly nix run, nix shell or nix profile install a package.

On my flake based system, I have a local copy of nixpkgs at /etc/nix/inputs/nixpkgs. I think this is due to my personal config, but I'm wondering if a default nixos system keeps a copy of nixpkgs anywhere that could be used to build the database using the meta fields? My apologies if it's already doing this.. I'm not a dev. 😁

[OleMussmann]

Good idea to get the necessary infos out of nixpkgs. As far as I know, there is no comprehensive index stored locally, neither as a copy of nixpkgs, nor as package metadata information.

Pulling the nixpkgs repository and extracting the information from there looks robust to me. However, the whole thing is at least (shallow clone) 650Mb. The entirety of /pksg/by-name/ is still 309Mb. It's a rather big ask to have users download and build the search index from that.

The next days I will experiment with setting up a separate project that uses GitHub Actions to regularly (daily?) build a compressed SQLite package metadata database. If that is small enough, then nps can download that database when updating the package info.

Unrelated to this issue, could you tell me more about the kitty shortcuts? Sounds useful.

[kevb1973]

Sounds cool. I'll be interested to see what you come up with!

For the kitty binds, I have the following. I think I had issues getting it to work if I included the nix commands directly in the bind, so I had to put them in a script and then call that.

kitty.conf binds:

map kitty_mod+t kitten hints --hints-background-color #dce0e8 --type=regex --regex='(?m)(^[\S]+)' --program 'launch --type=tab --tab-title '<nix-shell>' kitty-ns'

map kitty_mod+i kitten hints --hints-background-color #dce0e8 --type=regex --regex='(?m)(^[\S]+)' --program 'launch kitty-npi'

kitty-ns script:

#!/usr/bin/env bash

nix shell nixpkgs#$1 -c fish

kitty-npi script:

#!/usr/bin/env bash

nix profile install nixpkgs#$1

Usage:

ctrl-shift-t: "Try" package. (I have ctrl-shift-s already used for opening scrollback in nvim for copying by keyboard)
ctrl-shift-i: "Install" package to user profile.

These binds will create hints to the onscreen package names from the nh search output. It even works in scrollback which is nice. It calls the scripts above which either opens nix shell in a new kitty tab (and starts fish shell which is optional) or installs the package to the user profile in a split window and then disappears. My regex skills are lacking so it hints some stuff that isn't a package name, but it works well enough for me and it's handy.

Edit to add: For nix-search-cli I used this regex: --regex='(?m)(^[a-zA-Z0-9]\s).*'