feat(modules): use package set for port sources

[getchoo]

Closes #240

The main goal here is to avoid discrepancies with the versions of Nixpkgs we have tested on and those on our users' systems -- i.e., us falling out of sync or moving too quickly with Nixpkgs will no longer cause problems in our modules

As a side effect of these changes, we also see some other improvements:

• No more builtin fetchers
  • Builtin fetchers have a large effect on evaluation by blocking it to download files -- similar to IFD. This is why they are not allowed in Nixpkgs.
  • Using Nixpkgs' fetchers allows us to download most sources at build time, considerably improving evaluation performance for those who use many of our modules
• Less space taken up by (most) sources
  • Done by only packaging what's needed by the module
  • This should make interacting with sources much easier
  • It also allows us to easily share modifications to ports across home-manager and NixOS
• Fewer rebuilds
  • Some derivations brought over from Nixpkgs have been modified to build and install all variants instead of only one set. While this slightly increases storage use, it avoids rebuilds when you change your accent, flavor, etc options

[gador]

I believe this broke eval on my hydra instance:

in job ‘mac’:
error:
       … while evaluating the attribute 'value'
         at /nix/store/3cbplia94qgrzhcjzvxqxcxpjj52x3nl-source/lib/modules.nix:846:9:
          845|     in warnDeprecation opt //
          846|       { value = addErrorContext "while evaluating the option `${showOption loc}':" value;
             |         ^
          847|         inherit (res.defsFinal') highestPrio;

       … while evaluating the option `system.build':

       … while evaluating the attribute 'mergedValue'
         at /nix/store/3cbplia94qgrzhcjzvxqxcxpjj52x3nl-source/lib/modules.nix:881:5:
          880|     # Type-check the remaining definitions, and merge them. Or throw if no definitions.
          881|     mergedValue =
             |     ^
          882|       if isDefined then

       … while evaluating definitions from `/nix/store/h7ky5a89kq9n96hwcnk42ir977bf4z5j-source/modules/system':

       … while evaluating the option `home-manager.users.gador.home.file':

       … while evaluating definitions from `/nix/store/xm5jfczg8vk87z70x0rcrjr04j1m6gbc-source/modules/misc/xdg.nix':

       … while evaluating the option `home-manager.users.gador.xdg.configFile':

       … while evaluating definitions from `/nix/store/xm5jfczg8vk87z70x0rcrjr04j1m6gbc-source/modules/programs/alacritty.nix':

       … while evaluating the option `home-manager.users.gador.programs.alacritty.settings':

       … while evaluating definitions from `/nix/store/rgwcvkpzdhy6rqpn6509a1qwqjn6rg5f-source/modules/home-manager/alacritty.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: a 'aarch64-darwin' with features {} is required to build '/nix/store/l8l4fqdz4gygj8j8f8ikllnhan13r8ix-catppuccin-install-hook.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, ca-derivations, kvm, nixos-test}

(and yes, it has been working before and the only major change was this PR)

[getchoo]

This is going to be an expected breakage with this change. Moving to nixpkgs fetchers over their builtin equivalents reveals some previously hidden occurrences of IFD, with the Alacritty module being an example of this

I'm assuming what's been happening here is that you have a Hydra instance with no aarch64-darwin builder, but that evaluates (not builds) an aarch64-darwin configuration. Previously this worked as the builtin fetchers are system agnostic, which allowed you to download the alacritty source even though it was technically for a different system; the Nixpkgs fetchers are system-specific though, so this is no longer possible

The only workaround here would be to disable the offending module on this configuration, or don't evaluate this configuration in your Hydra instance

[gador]

I'm assuming what's been happening here is that you have a Hydra instance with no aarch64-darwin builder,

Actually, the hydra instance is an x86_64-linux but has access to an aarch64-darwin builder. But I guess the evaluation is happening on the linux box.

The only workaround here would be to disable the offending module on this configuration, or don't evaluate this configuration in your Hydra instance

Well, this sucks. I like to pre-build my configurations and save them to an S3 instance. Is there no way to fix alacritty or have a workaround? Right now I pinned catppuccin-nix to the revision before this PR

[getchoo]

Is there no way to fix alacritty or have a workaround?

If your Hydra instance does have access to an aarch64-darwin builder, I would recommend setting up distributed builds between that and the evaluation machine, as it would allow latter to perform builds on the former and then continue evaluating. Alternatively, you could override the source used via catppuccin.sources to use the builtin fetcher once again -- but I would only recommend this if all else fails

[gador]

If your Hydra instance does have access to an aarch64-darwin builder, I would recommend setting up distributed builds between that and the evaluation machine, as it would allow latter to perform builds on the former and then continue evaluating

Well, this already exists and I could evaluate and build my whole aarch64-darwin config before..