Fontbakery: Custom profiles based on our documented approach fail after #3208 refactor

[chrissimpkins]

The fontbakery GH Actions FB main branch checks on a custom profile began to fail after #3208. It looks like the issue is that the Section import from checkrunner as documented in the fontbakery docs:

# maybe at the top of the file
from fontbakery.checkrunner import Section

# you can use a another name for the default section
# but this is what get_module_profile would do
profile = profile_factory(default_section=Section(__name__))
# IMPORTANT: after all checks etc. have ben defined:
profile.auto_register(globals())

moved to a new module path. A quick glance through the PR suggests that the PASS, WARN, FAIL import paths change as well.

This appears to be a backward incompatible change. We should update the custom profile docs with the changes that happened before this is released. It might be helpful to, at least temporarily, re-export the refactored imports from the previous paths and publish a transition guide for those who developed custom profiles based on the docs.

cc @simoncozens

[simoncozens]

Oops - sorry. I thought I had reimported them in the previous modules, but clearly not. Yes, they should be reimported.

[felipesanches]

Thanks, @simoncozens ! I've just merged that PR.

@chrissimpkins, please let us know if this is good enough to get the GHAction back to a good working state.

[felipesanches]

please reopen the issue if more tweaks are still needed

[chrissimpkins]

I can confirm that the custom profiles that I use for testing build against the changes in main after https://github.com/googlefonts/fontbakery/pull/3211. Thanks @simoncozens!

@felipesanches This was an issue with a change in the fontbakery API that broke any fontbakery custom profile that is based on current production docs. If we are heading to a new module structure, a custom profile documentation update is likely still warranted. As far as I can tell, the re-imports support those who are based on the old approach. The docs would steer future custom profile developers to use the new approach in case these are deprecated import paths that you plan to remove at some stage down the road.

I'd be happy to have a look at the docs this weekend if someone else doesn't get to it first.

[simoncozens]

I don't have a problem with the reimports being (semi-)permanent. The point was to make fontbakery's internal code tidier, rather than specifically to move to a different class layout in fontbakery's API.