Nix-index can't see wrapper packages

Development
1

tl;dr: should Nixpkgs build wrappers on Hydra, or should nix-index use something other than Hydra, or neither?

I use comma with nix-index-database to make it easy to run stuff. Today I tried to run NH like this:

$ , nh home build
> Building Home-Manager configuration

I was assuming I would see nom output, but instead there was just nothing as my fans spun up. I did some debugging and realized that this is because comma actually only sees the nh-unwrapped package, not nh:

$ , -p nh
Packages that contain /bin/nh:
- nh-unwrapped.out

Since from comma’s perspective there’s only one choice, it automatically chooses nh-unwrapped, which does not include nom.

The reason this happens is because the nh package includes this line in its meta:

hydraPlatforms = [ ];

So I opened a PR to fix the issue:

But someone pointed out that actually, this pattern of disabling Hydra is shared by many such wrapper packages (I estimate 81 from a quick check), apparently for efficiency.

I can think of the following three options for this situation; which makes the most sense?

  1. Remove hydraPlatforms = [ ] from these wrapper packages so that nix-index (and thus comma) can see them.
  2. Modify nix-index to not ignore every package that isn’t built by Hydra.
  3. Do nothing.
1 Like
2

Nix-index can’t work on packages that aren’t built by hydra, unless you have another cache (or it builds them locally, which is prohibitively expensive). The information necessary to do so just doesn’t exist.

Another potential solution is to add a side channel to the meta information of some packages listing binaries expected to be produced in $out/bin, which makes its way into nix-index and the database produced by the channel release process in addition to the information from the build results. This method could also allow these mechanisms to work for unfree packages.

1 Like
3

It seems like such a thing must already exist to enable https://search.nixos.org to list the “Programs provided” for a package (e.g. coreutils); is that the case?

4

No, I expect that’s working from the hydra builds just like nix-index does. (And the meta.mainProgram attribute which is used for lib.getExe and nix run, but can only inform the existence of a single binary name)

5

Including meta.mainProgram does seem like an improvement; it would fix the issue for NH at the very least. Would that make sense to do in nix-index, or would it make more sense to do in comma specifically?

6

Probably nix-index, I suppose, since for performance reasons you’d want it cached in the database, and nix-index produces the database.

1 Like
7

OK, I opened a PR:

2 Likes