/marvin opt-in
/status needs_reviewer

Hi! I'm an experimental bot. My goal is to guide this PR through its stages, hopefully ending with a merge. You can read up on the usage here.

Is this going to influence the speed of the bash-completion script when doing nix-build -A Tab?

@SuperSandro2000 The evaluation cache in Nix master speeds up tab completion, e.g. nix build nixpkgs#firef<tab>.

I don't think this would affect bash completion for nix-build -A at all as that simply evaluates the specified Nix file itself.

AFAICT, this file is only used in the build script of pkgs/top-level/make-tarball.nix and the only user of this expression's output I know of is Repology.

nix search might be using it but it's pretty fast and the amount of packages in the JSON "only" increased by ~13%; if something were to use it, the slowdown would not be all that significant.

/status needs_reviewer

A few questions:

• How was the list generated - I'm assuming by just looking for dontRecurseIntoAttrs in top-level/all-packages.nix - and can we add a comment indicating how to regenerate it if need be? (I guess that new packagesets like this aren't added particularly frequently)
• Does it matter if e.g. nodePackages and nodePackages_latest are both present (and emacs{26,27}Packages)? Do we need both (I assume yes because some packages might be disabled under older/newer versions of their respective runtime)?

How was the list generated

I don't think it was generated. It looks like it was picked out manually.

If we add another larger subset of packages, we should just manually update the list. That's a rare enough of an occurance to not cause too much trouble I think.

Does it matter if e.g. nodePackages and nodePackages_latest are both present

For Repology, it doesn't matter. They take care of duplicates etc.

I don't know whether there are other users but I'm pretty sure there aren't. I the only thing I can think of that could possibly be using it is nix search but I'd have to check.

If there are users who can't deal with duplicates we could either just export the latest versions or export the longer list as a separate JSON (maybe even the nearly complete list).

I assume yes because some packages might be disabled under older/newer versions of their respective runtime

Yeah that's what I was thinking too. Although, the set of packages not in both sets probably isn't too large in most cases.

/status needs_merger

@veprbl, you added a 😕 reaction to #102509. Is there a reason for that?

I'm a bit -0 on this one, since it does not addresses the real problem. Somebody will have to keep this list manually up to date. It would be nicer if this list would not be even needed. But I understand that this solved the problem currently, therefore I'm not against it, but would like to challenge that the problem to be addressed at the root.

Reminder: Please review!

Reminder: This Pull Request is awaiting merger. If you are the assigned reviewer with commit permission, please have a look. If you can't, please say so. If the status is not accurate, please change it. If nothing happens, this PR will be put back in the needs_reviewer queue in one day.

Since this discussion has stalled a bit and it seems like nobody is working on a better solution, I think something is better than nothing for now. So I'm calling "FCP with predisposition to merge" now. Unless somebody disagrees, I'll merge on Wednesday.

The only thing I was worried about being affected would be nix search but it seems like that generates its own json.

Reminder: Please review!

Reminder: This Pull Request is awaiting merger. If you are the assigned reviewer with commit permission, please have a look. If you can't, please say so. If the status is not accurate, please change it. If nothing happens, this PR will be put back in the needs_reviewer queue in one day.

:o

Issue on fixing this properly: #107539

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

https://discourse.nixos.org/t/nixpkgs-has-been-the-largest-repository-for-months/10667/1