Should eza configured for icons install icons?

Development
1

This question is probably somewhat philosophical. I wonder if somebody has a clear answer to it, as I’m conflicted and lack knowledge.

To install eza with icons enabled using Home-Manager, several config options need to be defined:

{ pkgs, ... }: {
  fonts.fontconfig.enable = true;
  home.packages = [
    (pkgs.nerdfonts.override {fonts = ["FiraCode" "DroidSansMono"];})
  ];
  programs.eza = {
    enable = true;
    icons = true;
  };
}

I suppose there is a certain flexibility in the choice of the exact nerdfont. I just didn’t know they were required at all. Icons were just broken.

So I wonder if it would be feasible and desirable for the eza module to install (at a least fallback) fonts automatically once enabled? Nix tools generally do an awesome job of configuring “everything required” for a given thing to work. This seems to be an exception. Is that a technical limitation? A design choice? An oversight?

The language is still flexible enough to fix this pretty cleanly on the user level, though it’s not quite satisfying:

{ pkgs, config, lib, ... }: {
  # boolean config is deprecated, but works for now
  fonts.fontconfig.enable = config.programs.eza.enable && config.programs.eza.icons; 

  home.packages = [ ... ] ++ lib.optionals config.fonts.fontconfig.enable [
    (pkgs.nerdfonts.override {fonts = ["FiraCode" "DroidSansMono"];})
  ];

  programs.eza = {
    enable = true;
    icons = true;
  };
}
1 Like
2

What’s difficult though is that a CLI application doesn’t really have a good view of the GUI stack used to display itself, and the fonts are a part of that GUI stack… Also you’re showing home-manager options but what about NixOS options?

For example the icons/glyphs could be already setup in NixOS, or be builtin in your chosen terminal application (like Wezterm), or some other ways… And the config that installs eza has no way to know.
I don’t think it’s really feasible to make a CLI app install fonts for that reason

3 Likes
3

It can perhaps make sense for the home-manager module. I don’t actually use icons much myself, but I can see that if someone wants to have it always on, it may make sense to also enable fontconfig and nerdfonts with a priority lower than mkDefault and higher than 100. I think it makes the most sense to keep this in home-manager, eza isn’t really the kinda software to get a nixos module.

I think work in the direction of what was present at nixcon with module contracts would make stuff like this a lot easier for terminal software like eza, so that all terminal software can have an unified interface to configure such things1 (even if I don’t think the approach presented is without flaws).

If there is some indication that users of the home-manager module would prefer this behavior, I can help you make a PR against home-manager adding this behavior, it shouldn’t be very hard if all it takes for the easy case is fonts.fontconfig.enable = true and adding nerdfonts. This may not work on all terminal emulators without additional setup, but upstream eza uses kitty as our reference for what is a mostly well behaved (or sane) terminal, so I think if it works for that it’s fine.

4

Interesting idea. Seems like a good, simple place for a first contribution and I’d appreciate your support. The only question that remains: How do we figure out what other users want?

5

I think we could just go ahead, since no one has replied about this yet. Usually there may be more comments on the actual PR, but this is probably not very controversial.

6

Alright. I’ve not yet made a public contribution to nix, I’m unfamiliar with the HM repo and I’m a little short on time, but this is a good opportunity and I’ll try to get to it. I’ll let you know once I have something

1 Like
7

There’s another case to consider, which is where the CLI app is installed and configured on a server for remote login, and should use icons because the (remote) clients are expected to have the fonts installed, but should not have any gui components installed locally.

1 Like
8

Do you have any idea on how to detect we are in such a scenario?

9

Well, you’re mostly talking about changing the defaults, and installing some fonts, right?

Currently, a user in the scenario I describe is served by the default; they don’t need any fonts and don’t get any without extra steps. It’s an entirely valid question as to whether that’s a sensible default that helps the largest number of users have the simplest configuration - probably not. As long as that user has an easy option to change the default, it’s fine.

It’s not so much a matter of detecting it magically. The comment is simply to make sure that the combination remains possible. My suggestion is that programs.eza. has another attribute, fonts, that defaults to the value of icons, and controls whether the fonts get drawn in as well. If you want icons but not fonts you simply set both explicitly.

As an aside, the nerdfonts collection was recently split up, so installing one or two doesn’t need that override anymore.