How checks are actually run

[simoncozens]

I'm trying to work out how the checkrunner works, i.e. at what point we actually get a list of checks and run some method on them to execute them. In a simple system, this would be something like

results = [ check(**args) for check in profile.checks ]

In Fontbakery, what actually happens is:

• check_profile calls runner.run() which does not actually run the checks! Instead it returns a generator:
  • This generator is actually composed from a session generator and a next check generator via drive_session_protocol.
    • The session generator is created by CheckRunner.session_protocol_generator, which combines a check_protocol_generator and the check order, using session_protocol_generator (a separate function).
      • The check protocol generator (when iterated on) gets the next check and actually runs it, yielding status, message.
    • session_protocol_generator (the function) runs the check protocol generator, yields its results and also builds a per-section summary, yielding that at the end as well.
  • The next check generator is just an iterator containing the order of checks.
• Now we have a generator which is composed of things which are composed of other things which, if you run through it, runs the checks. Hooray.
• distribute_generator actually runs through that iterator and sends its results to the targets, which are the various reporters you have configured.

I can kind of see the logic to this. But it's not terribly easy to follow.

[twardoch]

Add this to the docs!

[simoncozens]

If something so complicated it needs a long explanation, you can either document it or make it simpler. I prefer the second...

[twardoch]

I agree :) There could be

from fontbakery import bake

md = bake.md_report(paths=["path/font1.ttf", "path/font2.ttf"], profile="googlefonts")

html = bake.html_report(fonts=[ttFont1, ttFont2]) # default profile "universal"

[twardoch]

So #4397