Consider refactoring into a plugin based structure

[jspaaks]

Currently (0.14.1) the set of tests is baked into the library. There is no convenient way of customizing which tests are run, what they do, or to extend the set of tests with additional tests. If we want to facilitate this, we should consider refactoring the current structure into a plugin-based architecture.

The base howfairis library should then offer the infrastructure to run tests and report on their results. The tests themselves should come from a plugin (i.e. from a separate library, not necessarily made by us). Under this scenario, howfairis should have a loader to discover what plugins are available on the user's system / in their environment. It should also provide an abstract base class for a check, AbstractCheck, which plugins can then implement. The base class should probably have a property (to be overridden in the plugin's implementation) defining in which of the 5 categories the Check's results should be reported (TBD: are there any Checks that fall outside of the 5 categories?)

Tests like

howfairis/howfairis/mixins/citation_mixin.py

Lines 40 to 51 in 008552b

	def has_citationcff_file(self):
	""" """
	url = self.repo.raw_url_format_string.format("CITATION.cff")
	try:
	response = get_from_platform(self.repo.platform, url, "raw", apikeys=self._apikeys)
	# If the response was successful, no Exception will be raised
	response.raise_for_status()
	except requests.HTTPError:
	self._print_state(check_name="has_citationcff_file", state=False)
	return False
	self._print_state(check_name="has_citationcff_file", state=True)
	return True

should be moved into a separate plugin library, maybe something like howfairis-nlesc

To help rate limiting, it is probably helpful if Check's __init__ can take some commonly required data as its argument, for example the contents of the readme.

Refer to https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/ for more information on various plugin discovery methods.