What is the right way to add optional pkgs to nixos binary cache?

Hi guys. Is there a right way to add optional package, like openvpn3 (for resolved) to the binary cache? I’m using resolved, which means I need to build this package because it is overridden in the module.

Now I have the same problem with swayfx. After that PR which adds support for packages with arguments like the standard package to override them and apply the module options.

At this point, I see two ways how this is happening:

  1. Sway has an argument isNixOS = false, but after overriding by the module, the package is still present in the binary cache. I attribute it to the module tests.
  2. Some optional packages are defined in all-packages, which adds them to the cache.

But I think both of these options look weird in my case. Maybe I’m missing something?

Could anyone more knowledgeable than me tell wether this will get cached?

passthru.tests.with-systemd-resolvd = finalAttrs.finalPackage.override { enableSystemdResolved = true; };

Or possibly, contribute a nixos test?

passthru.tests derivations will not be built by hydra, and therefore won’t be cached (unless something else references them).

3 Likes

openvpn3 is built and on cache.nixos.org
Hydra - nixpkgs:trunk:openvpn3.x86_64-linux

But not the .override { isNixOS = true; }; version, used in the nixos module.

This is not a scalable solution, but some attributes in nixpkgs exist just to make hydra build additional variants of packages, e.g. python3Packages.torchWithRocm

Yes, with resolv.conf, but not with resolved as the default resolver, which is used if you have services.resolved.enable = true, which is exactly what the PR I mentioned does.

what attributes? didn’t find any hydra-specific attributes in torchWithRocm derivation

Serge is asserting that the torchWithRocm attr itself exists to make hydra build a variant of the torch package to ensure it’s available in the cache.

Ah, that’s exactly what I was talking about here: