@timokau To answer to #105857 (comment): Yes, this adds a list that would need to be maintained. Even after the selections there are some items that are not sets of installable packages (e.g. texFunctions).

adds a list that would need to be maintained

True but I feel like we kind of need a list like this. There is no source for what's a set of packages under pkgs and what isn't. Not good for discoverability; neither automated nor manual.

As @garbas mentioned though, ideally this would be resolved at the root: Perhaps such a list should be the very place in which package subsets are defined.

What if we moved packages subsets out of all-packages, into a new "subsets.nix" and then combined back into the current pkgs structure for example? (+ perhaps a new pkgs.subsets)

Even after the selections there are some items that are not sets of installable packages

It'd be better if it was 100% clean of course but having sets with things other than packages in them isn't actually an issue because non-derivations are simply skipped in the JSON generation.

I marked this as stale due to inactivity. → More info

What is the status here?

It would still be great to export every package to packages.json. That is an easy way to make nixpkgs more valuable for users. Packages that are not discoverable do not exist for users!

#105857 was merged because there is no better proposed solution to solve the issue and i think that applies here too. So, can we get it merged?

The problem is not that this is a bad solution, the problem is that this is an unsustainable solution.

We need to enforce a single place where subsets must be declared and perhaps even apply recurseIntoAttrs to all of them.