Treat alias names like description

[nomeata]

I was searching for manpages (the package name I was used from Debian), but https://search.nixos.org/packages?channel=21.05&from=0&size=50&sort=relevance&query=manpages did not show anything. Then someone told me that manpages exists, leaving me confused. Finally someone explained that the search hides aliases.

Hiding alias from the results is sensible, but it would probably still make sense to use that data when searching, i.e. show man-pages when someone searches for manpages, as if manpages appeared in the description.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/man-pages-like-ascii/14699/6

[jtojnar]

Previously #115, removed in #309 since there is no simple way to detect if an attribute is an alias.

[nomeata]

there is no simple way to detect if an attribute is an alias.

I see. Can we maybe create a way to recognize an alias? Maybe extending setting a flag in the meta of the derivation in this function in aliases.nix:

  mapAliases = aliases:
    lib.mapAttrs (n: alias: removeDistribute
                             (removeRecurseForDerivations
                              (checkInPkgs n alias)))
                     aliases;

But that would not be enough, I guess, since you’d also have to know the derivation it maps to…

Maybe aliases.nix could become more declarative, and define the common aliases as a list of mappings from sting to string that can be consulted by nix search directly, in addition to being turned into the set of attributes.

But maybe this is too much of a change for this not very big itch.

[ulysses4ever]

I confirm, as a novel Nix user, that I ran into the searching by alias problem multiple times and heard from people who also had that. The web search serves novices in large part (I imagine), so it should strive to make any usability improvement it can (I.e. saying: just use nix search doesn’t really suffice).

I understand that there’s a technical challenge here, so… Just a user report that it would help if there was a volunteer who implements it.

[jtojnar]

I would say it would be better to just improve package descriptions, rather than try to do anything with legacy aliases that will eventually get removed. Or add tags to packages. Or make the search fuzzier.

[nomeata]

Good point. Maybe we can simply add useful aliases to the package descriptions manually? Throw in a simple took that looks at aliases.nix and reports aliases that don't contain ther name in the aliases? And, if necessary, add an “extra index words” list to the package meta to add them without artistically changing a good description.

This might be easier to pull off, and yield better results

[ncfavier]

Another problem is that, even ignoring aliases, nix-env will not include syntactically duplicate derivations (https://github.com/NixOS/nix/commit/4eb637c799bddfcff7661164f98cd604fe4120f5), so e.g. linux_latest is not included.

I'm starting to think we should stop relying on nix-env to get packages from nixpkgs and just treat nixpkgs like any other flake... @ysndr thoughts?

[ysndr]

That was the plan initially, but was blocked since nixpkgs is based on legacyPackages which are

a) not evaluated/listed by nix flake show b) troublesome to evaluate by hand (all the nixpkgs_allow_* stuff)

* Support for legacyPackages is actually present already (maybe just not exposed)

Maybe your recent changes in nix changed the situation a bit (i dont keep up too closely with nix).

Last time avoiding evaluation was only possible if nix had a more thorough --json flag for nix flake show and nix flake show --legacy. However, i don't know if that would change the alias situation.

[ncfavier]

This came up again: https://github.com/NixOS/nixos-search/issues/563

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/non-transitional-aliases-redirects-in-nixpkgs/34413/2