Generate unbound configuration files from blocklist files

[Yethal]

• Generate unbound.conf files from each hosts file in repository
• Add an overlay exposing the confs files under unboundconfs nested scope
• Unbound users consuming the flake are now able to import the blocklists via config similar to this:

{pkgs, ...}:
{
  services.unbound = {
    enable = true;
    settings = {
      include = [
        pkgs.unboundconfs.fakenews-gambling-porn
      ];
    };
  };
}

[welcome]

Thank you for submitting this pull request! We’ll get back to you as soon as we can!

[toastal]

Why not split the string once in the let block instead of twice? What happens with null?

[Yethal]

Not sure what you mean by null with this case. We're splitting the hosts file on newline and apply transformation to all lines that aren't comments or empty lines

[toastal]

elemAt returns a value or null. Are there cases where this can fail?

[Yethal]

Yes, on empty lines which we're skipping in the if statement

[toastal]

This block would probably run faster as a single fold instead of iterating the whole list 3 times (4 including the post-let mapAttrs). If it isn’t that expensive, I still think lib.pipe would be a lot easier to read this case instead of trying to read the block backwards from lines bottom to top.

[Yethal]

When I originally wrote this I was using the experimental pipe-operator and then converted the code to the original pipe-less nix but lib.pipe does seem like an okay compromise

[toastal]

Gotcha. The pipe change here I think is a lot easier for the reader to follow.

[Yethal]

I completely agree but I wasn't sure what's the consensus regarding usage of lib.pipe. In my own nix code I just use pipe operator everywhere but I understand this is not common practice

[toastal]

Why 2 commits reverting a formatting instead of amending to fix the single commit? Some of the formatting would be addressed tho with https://gitlab.com/StevenBlack/hosts/-/merge_requests/2 or #2813

[toastal]

Additionally, there is a smell about directories. You should probably be filtering on just hosts files with lib.fileset so READMEs, PNGs, & such do not a) cause a rebuild if changed & b) aren’t copied to the Nix store since they wouldn’t be relevant. It’s a little hard to tell if that’s what’s happening here or not without a src, but it could be worth having a look. It could also be an alternative to the lists variable being quite long in packages to just filter on the types you need first instead of mechanically testing.

[Yethal]

@toastal I am filtering on hosts files, no other files within /alternates are considered, it's just pipe-less Nix code with multiple chained functions is difficult to read

[Yethal]

Given the include field in unbound config is a list we could optimize this even further by only generating packages for non-combined list variants and allow users to combine them themselves by adding multiple entries to include list so instead of

{pkgs, ...}:
{
  services.unbound = {
    enable = true;
    settings = {
      include = [
        pkgs.unboundconfs.fakenews-gambling-porn
      ];
    };
  };
}

People would do

{pkgs, ...}:
{
  services.unbound = {
    enable = true;
    settings = {
      include = [
        pkgs.unboundconfs.fakenews
        pkgs.unboundconfs.gambling
        pkgs.unboundconfs.porn
      ];
    };
  };
}

[toastal]

No opinion on trying to shorten the list, but generally looks good

[Yethal]

This drops the amount of packages to evaluate from 30 to 4 so should speed up evaluation as well.

[Yethal]

@toastal Is there anything else to do here or can we merge?

[toastal]

Nope. I am not a maintainer… I also have Nix changes open.

[Yethal]

@StevenBlack I believe I require your assistance with this.