Previously we used nodePackages only to fetch Iosevka's build
dependencies and then fetched the source code ourselves. Updates
involved changing the version and hashes in the `iosevka` derivation and
then running node-packages/generate.sh to update the build dependencies,
which in turns updates *all* of node-packages.nix.
A new proposed policy for handling node-packages.nix updates involves
batching those updates. Previously, that would mean `iosevka` and its
build dependencies could end up out of sync until the batched update was
run.
To work with the new policy, we now fetch Iosevka's source code (and
not only its dependencies) through nodePackages. Updates are done by
changing the source URL in node-packages.json, which eventually becomes
part of an update of node-packages.nix, which is then propagated to
`iosevka` itself.
One con of this strategy is that errors can not be caught directly
after the update, but only after node-packages.nix is regenerated.
This adds the ability to select a specific prebuilt variant. It also adds
an updater script for generating their hashes. Additionally, switching
to TTC files reduces the package size by an order of magnitude.
Example usage:
fonts.fonts = with pkgs; [
(iosevka-bin.override { variant = "ss10"; })
(iosevka-bin.override { variant = "sparkle"; })
(iosevka-bin.override { variant = "aile"; })
];
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
After some back and forth with JoyPixels they agreed to creating a
version of their font for macOS that does not use the exact same name as
the Apple Color Emoji default font.
This naming collision meant it was impossible to configure applications
to use the JoyPixels emoji font unless you disabled the Apple Color
Emoji font using Font Book. Which meant the JoyPixels font could either
replace the Apple Color Emoji font completely or only fill in the gaps
in that font (on my system "hot face" isn't in the system font) but not
be used entirely for specific apps or be used with the system font as a
back up.
By moving the assert concerning license acceptance into the src
attribute license acceptance can be expressed with an override,
`joypixels.override { acceptLicense = true; }`.
Specifying the system-specific variables for x86_64-darwin and
x86_64-linux is too restrictive, excluding for example i686-linux.
Since macOS seems to be the odd one out we can special-case only
x86_64-darwin.
