nerdfonts: separate into individual font packages, 3.2.1 -> 3.3.0

[rc-zb]

Separate Nerd Fonts into individual packages under the namespace of nerd-fonts.
And update it to 3.3.0.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Mention the package maintainers

@doronbehar

---

Add a 👍 reaction to pull requests you find important.

[r-vdp]

Should we not create a top-level attribute for each font, and then an additional one that bundles all of them?

[r-vdp]

Suggested change

	builtins.listToAttrs (
	map (font: lib.attrsets.nameValuePair font.attrName (makeNerdFont font)) (
	lib.trivial.importJSON ./fonts.json
	)
	)
	symlinkJoin {
	name = "nerd-fonts";
	paths = map makeNerdFont (lib.trivial.importJSON ./fonts.json);
	}

[r-vdp]

We need to produce a single derivation here, containing all fonts, right?

Maybe you want to use callPackages instead (note the s at the end), and then additionally add the symlinkJoin to the set to have a derivation containing all fonts.

[rc-zb]

I don't think bundling different fonts together (as in the legacy nerdfonts) is a good idea. They have different origins, different descriptions, different licenses and different tarballs. I.e. they have nothing to do with one another except that they live and get patched in the same repo. Should we agglomerate them together, we would have to bundle many of the kdePackages together too, which is so meaningless as well as impractical.

[r-vdp]

I meant that we remove the code for the old derivation altogether, we add the new derivations, and we add a symlinkJoin with all of them as the replacement for the old package.

[rc-zb]

No... Even if we manage to make such a mono-package, either it can't share the interface with its predecessor, or it shares the defeat as well -- difficulty to be built by Hydra due to its too many variants. On the other hand, the user may choose all the fonts by just appending the whole package set to their "fonts" or "packages" list.

[r-vdp]

Well no, that's the thing of symlinkjoin, it just symlinks. So the package would be tiny, it just links to all the others.

[rc-zb]

I don't know what Hydra actually do to build the cache. But if it was overwhelmed by the old package, which fetched only one GiB or two of tarballs, it must had made a huge number of random compositions on the overridable font choices. For the new package set, however, you can just mix the fonts in any manners as for other packages. Specifying font members and building a dedicated mono-derivation, lightweight or not, is quite redundant.

[doronbehar]

I agree with @rc-zb in this topic. I'll only add that if someone really wants to get all the fonts they can use Nix code to simply take all attrValues of nerd-fonts.

[r-vdp]

What's the reason for keeping the old derivation?

[doronbehar]

Beautiful work! Thanks :). I can't believe only now someone has thought about this.

[doronbehar]

simply vendoring both files - upstream's release SHA-256.txt, and fonts.json, and with pure Nix, generate the derivations

If the font families information were still needed, we would have to download and unpack the tarballs and fc-query the info anyway.

Then I think at this point I would let it go - it is not that important and usually in people's configuration the font families of each font is something that should stay constant in future releases of nerd fonts.

[doronbehar]

I agree with @rc-zb in this topic. I'll only add that if someone really wants to get all the fonts they can use Nix code to simply take all attrValues of nerd-fonts.

[doronbehar]

Maybe it'd be easier to use lib.genAttrs?

[doronbehar]

You can use strings here,

[rc-zb]

Then I think at this point I would let it go

Now it goes.

[doronbehar]

Sorry for taking so long to reply, I'm pretty busy. I also wish I could have helped more directly by simply checking out locally the PR and testing and pushing my suggestions.

[doronbehar]

I think the version of the nerd-fonts release tag should be used here, and this would allow you to take slightly less info from that large release info json file.

[rc-zb]

This would break the consistency among versions of different fonts. And if the upstream does not want to specify some of the individual versions, why do we care about them?
The size does not matter, because there is only one published_at in the response.

[rc-zb]

and the update script could be a simple bash script grabbing the latest release's SHA-256.txt file and fonts.json

So eventually some sort of "algorithms" are still needed for the script? And the checksums JSON become similar to the one before refactoring, except for the removal of nix-prefetch-url...😂

[doronbehar]

and the update script could be a simple bash script grabbing the latest release's SHA-256.txt file and fonts.json

So eventually some sort of "algorithms" are still needed for the script? And the checksums JSON become similar to the one before refactoring, except for the removal of nix-prefetch-url...😂

Not running nix-preferch-url per font was my main objection to the original design of the large JSON file. My original intention now was to make the update script as minimal as possible,, but I observed your insistence on using a "real" programming language, and it came out pretty nice, especially since converting from the original SHA-256.txt file format to some structured form is easier with Python and JSON v.s with Nix (with builtins.readFile), and because it allowed us to filter a bit the information from upstream's files that we vendor.

I pushed a few small improvements to the update.py script, that I think you'd easily agree with. The main big improvement I pushed is the support for the commit feature of update scripts:

https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#supported-features

Now you can run the script only with nix-shell maintainers/scripts/update.nix. This, and the support for the commit feature, are 2 more good reasons to use a real programming language.

Glad I finally found the time to help with this too :). Waiting to see your approval. Please note how you can git checkout HEAD^, and run:

nix-shell maintainers/scripts/update.nix --argstr path nerd-fonts --argstr commit true

And get the same result.

[doronbehar]

BTW Why did you decide to not use folderName here?

[rc-zb]

Because folderName is essentially the original name concatenated, not the font (family) name of the released patched font, some of which have to deviate from the former due to their RFN policy. Also, the texts in the preview images on the website are generated from patchedName instead of folderName.

[l0b0]

Love it; thank you! After installing pkgs.nerdfonts just to get a single font, and then getting a bit of a shock when looking at nix-tree, this is a welcome change.

[doronbehar]

Let's see a nixpkgs-review report when CI is green, and merge 🎉.

[doronbehar]

Fixed merge conflict in the last push, and labeled the PR so it will be backported to release-24.11.

[doronbehar]

I've also built all nerd-fonts manually (without nixpkgs-review) and it seems fine.