Change:
# Enable recursion into attribute sets that nix-env normally doesn't look into # so that we can get a more complete picture of the available packages for the # purposes of the index. <del> packageOverrides = super: let recurseIntoAttrs = sets: super.lib.genAttrs (builtins.filter (set: builtins.hasAttr set super) sets) (set: super.recurseIntoAttrs (builtins.getAttr set super)); in recurseIntoAttrs [ "roundcubePlugins" "emscriptenfastcompPackages" "fdbPackages" "nodePackages_latest" "nodePackages" "platformioPackages" "haskellPackages" "idrisPackages" "sconsPackages" "gns3Packages" "quicklispPackagesClisp" "quicklispPackagesSBCL" "rPackages" "apacheHttpdPackages_2_4" "zabbix50" "zabbix40" "zabbix30" "fusePackages" "nvidiaPackages" "sourceHanPackages" "atomPackages" "emacs27.pkgs" "steamPackages" "ut2004Packages" "zeroadPackages" ]; </del> <ins> packageOverrides = super: with super; lib.mapAttrs (_: set: recurseIntoAttrs set) { inherit (super) apacheHttpdPackages atomPackages fdbPackages fusePackages gns3Packages haskellPackages idrisPackages nodePackages nodePackages_latest platformioPackages quicklispPackagesClisp quicklispPackagesSBCL rPackages roundcubePlugins sconsPackages sourceHanPackages steamPackages ut2004Packages zabbix40 zabbix50 zeroadPackages ; # This is an alias which we disallow by default; explicitly allow it emacs27Packages = emacs27.pkgs; }; </ins> }

Discussion:
Describe the bug ! was something changed about the exported package list? Expected behavior same number of packages or even more Additional context we used to have the most packages, but now AUR is on top again
Maybe is part of this.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Might also be a redefinition of a "project" on the repology side, i.e. duplicates that weren't detected before. Projects != Packages. Do we know the revisions of before and after? We could check whether anything went missing from in the tarball because that's the source of Repology's data.
Well it must've happened on January 16th so we could use one commit from the 15th and 17th and see if there are suspicious changes in the that json file in between. Using we can pick a merge commit from the 15th e.g. and one from the 17th e.g.
We need to know the state of the unstable channel on those dates, it's days or sometimes even weeks behind master. Don't really have time for this right now but is probably what we need.
Well it must've happened on January 16th It did appear in Repology on 16. January, but our channel take some time after a commit was done. So i would check like the 9. Jan.. There was a successful channel evaluation on 2021-01-07. Channel evaluation: () packages file: () () () Latest unstable channel evaluation: () So the number of packages decreased by 8,990 between 2021-01-07 () and 2021-01-16 (). There was this change of emacsPackages to on 2021-01-13 () And it's indeed the emacs packages that are missing on 2021-01-16! ! Number of : Number of packages that are in but not in : Full list: For example . It does not exist in packages-2021-02- It does exist today in the search: But not on Repology: We should really be consistent here. The packages that nix can install from nixpkgs channel, and Repology should be identical!

, and so on were moved to their respective interpreters as & in Partly this is to fix the asymmetry of not having package sets available for the packages. The old names now only exists as aliases which probably explains why they have disappeared from Repology. I think this opens up a question regarding if we should remove from . We've tried this before and it makes tools like a lot slower since these package sets are pretty massive. Maybe we should only expose for the default Emacs package but not for the rest? That way we also don't count every package in the sets N times (where N is the number of distinct Emacs packages).
I think such tools should show packages only once, even when they exist for different interpreters like emacs26 and emacs27. But it should be obvious that you can use both. The raw package list should still contain all i guess, so tools like repology get all nixpkgs has to offer. But that is a big topic and it's about UX. For example in the search. Now it looks like this: ! But this would be less cluttered and more user friendly: ! (I opened an issue for that ) Same in .
The bug is probably here: did update the set names here too but I don't think sub-attributes work in that construct.
Nice catch! I've attempted to conjure up a fix in but it needs more testing before I'm comfortable merging.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Status: rPackages is fixed See for example "tidytidbits" on or . In the package set list is also emacs27, but i don't find any packages. When i search for random packages that existed before, like "pony-mode" i don't find it now in search or repology. The name does exist in which is not found in github search, probably because the file is too big. On repology you find only 1 emacs package in nixpkgs! So the package set emacs27 is still missing from .