Request: ability to use system-packaged Fontawesome if found?

[mattdm]

In Fedora, we have FontAwesome as an included package, and our packaging guidelines require bundled fonts to be ... debundled.

I've patched this in to my package build scripts (see https://mattdm.org/misc/fedora/pywaffle/python-pywaffle.spec), but it would be ideal if the library just noticed and used those. I guess this could be a "build time" thing, but I'm thinking maybe if

/usr/share/fonts/fontawesome5-free-fonts/Font Awesome 5 Free-Regular-400.otf
/usr/share/fonts/fontawesome5-free-fonts/Font Awesome 5 Free-Solid-900.otf
/usr/share/fonts/fontawesome5-brands-fonts/Font Awesome 5 Brands-Regular-400.otf

are installed, those could be automatically used -- with the mappings created at runtime from /usr/share/fontawesome5/metadata/icons.json.

That'd also benefit people who install via pip or whatever.

What do you think?

[gyli]

A major concern I have is the package is unlikely to be packaged and distributed for specific systems or system versions, in order to remain simple. So I don't see a way I can debundle the fonts for Fedora users only. If the package will ship with fonts anyways, it would be meaningless to use the system's fonts and generate mapping on it.

I am also thinking if it is feasible to create dedicated dependencies for Fedora. By checking PEP-508, I don't find an environment marker that can return Linux distro name.

Do you have any idea how it can be debundled for Fedora, or do you have any other Python packages as an example?

[mattdm]

What I'm currently doing:

1. Patch pywaffle/fontawesome/__init__.py to look at the system paths
2. Patch pywaffle/scripts/get_fontawesome.py to load the JSON from the local file in its Fedora location rather than a web URL (also removing requests, as that's not needed)
3. Run that script to regenerate pywaffle/fontawesome_mapping.py so it matches what's available in the local font.
4. Package that up into an RPM.

This is fine, but it means people will get a different experience if they install from pypi. Let me check with our python packaging experts and see what they think we should do.

[gyli]

Yeah, please let me know if I can package it in a different way, and ideally we can make it smaller for Fedora users.

FYI, I moved pywaffle/scripts/get_fontawesome.py to scripts/get_fontawesome.py to avoid confusion, as it's not included in the package, but only for development.

[gyli]

@mattdm — revisiting this, and #38 removes most of what you were patching downstream.

The two files you listed are both gone:

1. pywaffle/fontawesome_mapping.py is deleted. The mapping is now built at runtime from the installed fontawesomefree package's metadata/icons.json, so there is no generated file to regenerate or patch.
2. scripts/fontawesome_mapping_generator.py is deleted along with the setup.py install cmdclass that called it.

That hook was broken anyway, which is what forced the rewrite: it only runs for setup.py install, never for a wheel, so every PyPI release since 1.1.0 has shipped a Font Awesome 5.14 mapping applied to Font Awesome 6 fonts — 451 icon names raising KeyError and 83 drawing the wrong glyph. Worth knowing if Fedora is currently shipping the pip mapping rather than your regenerated one.

Font discovery is still centralised in one place, font_file_finder() in pywaffle/fontawesome_handler.py, alongside the new fontawesome_package_path(). So your remaining patch is one function instead of two files plus a build step.

What is still needed for a clean Fedora package, and what I would like your input on: making fontawesomefree an optional extra rather than a hard dependency, so Fedora can depend on the system fontawesome-fonts RPM instead. That means:

• fontawesomefree moves to [project.optional-dependencies], installed as pip install pywaffle[icons]
• a clear error when icons= is used and neither the package nor a configured font directory is present
• a documented way to point PyWaffle at a font directory and metadata file outside the Python package

The last item is the one that would let you drop patching entirely — an environment variable or a module-level setting that overrides fontawesome_package_path(). Does that shape work for how Fedora packages this, and is icons.json present in the Fedora fontawesome-fonts layout, or only the OTFs? If it is OTF-only I need a different way to build the name mapping, and I would rather know that before designing the override.

Deliberately keeping it out of #38, since making the dependency optional is a breaking change and that PR is otherwise pure bugfixes.

[mattdm]

Ooh, thanks! I'm super busy right now but I'll get back to you when I can.

[gyli]

@mattdm — no need to dig anything out, I found the answer. Two PRs open that between them do most of what this issue asks for.

Font Awesome is now optional (#59)

pip install pywaffle no longer pulls in fontawesomefree; icons come from pywaffle[icons]. Rectangle blocks and the characters parameter work without it. That alone unblocks packaging PyWaffle for Fedora without a vendored font.

PyWaffle can now use a system Font Awesome (#60)

PYWAFFLE_FONTAWESOME_DIR points at a directory of .otf files; failing that the Python package; failing that the usual system font directories, which include Fedora's. Distributions keep the upstream file names, so the existing style matching already recognises them.

The part I expected to be a blocker, and was not

I was going to ask you whether Fedora's font package ships Font Awesome's icons.json, because that was the only source of the icon-name to character mapping — and if it were fonts-only, the mapping would have to come from somewhere else.

It does have to, and it can: Font Awesome stores each icon's name as its glyph name. Inverting the font's character map recovers them, read through matplotlib's own FreeType binding, so no new dependency.

I measured what that costs, against the 1,959 solid entries in icons.json:

names recovered from the font	1,398
absent, all of them aliases	564
canonical icon names missing	0
resolving to a different code point	158

The 158 are because Font Awesome maps both a private-use code point and the matching real Unicode one to the same glyph. All 158 reach the same glyph, so nothing renders differently — verified by drawing the same chart from a fonts-only directory with fontawesomefree uninstalled and getting a byte-identical PNG, even though star resolved to U+2B50 rather than U+F005.

So: a system Font Awesome gives every real icon name and identical output. The only loss is aliases, which live solely in icons.json — circle-half-stroke works, its alias adjust does not. Documented plainly.

What would still help from you

Two things, whenever you have time — neither blocking:

1. Does the path list match what Fedora installs? I have /usr/share/fonts/fontawesome for fontawesome-6-free-fonts / fontawesome-6-brands-fonts, plus Arch's /usr/share/fonts/OTF and Debian's /usr/share/fonts/opentype/font-awesome. If Fedora puts them somewhere else, or splits them differently, I would rather fix the list than have you set an environment variable.
2. Is losing aliases acceptable for a distribution build? If not, packaging icons.json alongside the fonts would restore them — PyWaffle prefers it when it finds one next to the fonts or in a metadata/ directory beside them.

Keeping this issue open until you have had a chance to confirm the layout, since that is the part I cannot check from here.