Split checks from profiles

Last time I tried to add a profile (#3168), I was told that we shouldn’t proliferate profiles and that the checks should find their way into other profiles. I agree with this, it’s a good idea! The problem is that the checks need to be “put” somewhere and right now the only place we have to put them is a package called fontbakery.profiles. Now we are talking about the GRAD check (#3187). I’m happy to write a check but I don’t want to have to fight over which profile it should go in. These are separate concepts.

In fact, right now, we have some files in fontbakery.profiles which describe profiles, some which describe checks, and some which contain both checks and profiles. This is a bit crazy.

I would like to see a package called fontbakery.checks which contains all the checking code, with fontbakery.profiles reserved for actual top-level profile. Things in fontbakery.profiles should just load up the checks that they need and return a list. This is cleaner and it also means that the list of profiles can be automatically loaded from all the modules in the package.

Eventually the fontbakery.profiles stuff can probably go away and become a bunch of JSON files.

[simoncozens]

I love that idea, as it would also allow individual projects to pass configuration details to the checks. This would clean up eg the shaping check, by eliminating hard-coded data file paths.

[graphicore]

(Maybe we must make namespace a literal thing, we could mix stuff, detect collisions … 🤔 )

I understand why it’s a good idea to make software implementations as generic as possible. But at some point you have to specialize. This project is called fontbakery; a certain amount of specialisation is expected. 😃

Maybe, but it’s neither necessary nor do we have to. Instead of specializing check_runner, we should specialize fonts_profile. A profile is nothing else than specialization for a purpose and providing a generic interface for check_runner.

So you want to namespace profiles so that different profiles can define different “kind of things” that they test, and Felipe wants profiles to be able to test many different kinds of things!

I can’t follow this. I don’t think it compares well. Felipe wants the fonts_profile to do things, I want the check_runner to be unaware of those things.

I also want to have attached to each check the environment information (namespace) it expects, but a profile already does that. The pool, by convention, could provide that environment information.