Plugin system overview¶
For RepoBee to discover a plugin and its hooks, the following conventions need to be adhered to:
The PyPi package should be named
<plugin>is the name of the plugin.
The actual Python package (i.e. the directory in which the source files are located) should be called
repobee_<plugin>. In other words, replace the hyphen in the PyPi package name with an underscore.
The Python module that defines the plugin’s hooks/hook classes should be name
Task plugins that add command line options must prefix the option with
--<plugin>. So, if the plugin
exampleplugwants to add the option
--ignore, then it must be called
- The reason for this is to avoid option collisions between different plugins.
- Note that this does not apply to extension command plugins, as they do not piggyback on existing commands.
For an example plugin that follows these conventions, have a look at repobee-junit4. Granted that the plugin follows these conventions and is installed, it can be loaded like any other RepoBee plugin (see Using Existing Plugins).
There are two types of hooks in RepoBee: core hooks and extension hooks.
Core hooks provide core functionality for RepoBee, and always have a
default implementation in
repobee.ext.defaults. Providing a
different plugin implementation will override this behavior, thereby
changing some core part of RepoBee. In general, only one implementation
of a core hook will run per invocation of RepoBee. All core hooks are
Note that the default implementations in
simply be imported into the module. They are not necessarily defined
Extension hooks extend the functionality of RepoBee in various ways. These are
probably of most interest to most people looking to create plugins for RepoBee.
Unlike the core hooks, there are no default implementations of the extension
hooks, and multiple implementations can be run on each invocation of
RepoBee. All extension hooks are defined in
RepoBee has a notion of a task, which is a collection of one or more interdependent functions. The purpose of all tasks is to act on repositories. For example, the built-in pylint plugin is a task whose act consists of running static analysis on all Python files in a repository. The repobee-junit4 plugin is another task plugin whose act consists of running JUnit4 unit tests on production code in the repository. Tasks can run on master repos before they are pushed to student repos, or on student repos after they have been cloned.
An extension command is a top level command that’s added to the RepoBee
command line interface. The built-in
config-wizard command is implemented as
an extension command, and allows a user of RepoBee to edit the configuration
file. The repobee-feedback plugin provides the
command, which opens feedback issues in student repositories based on local
text files. Extension commands are pretty awesome because they integrate
seamlessly with RepoBee, can leverage some of RepoBee’s powerful CLI
functionality and can do pretty much whatever they want on top of that.
Implementing hook functions¶
There are two ways to implement hooks: as standalone functions or as methods
wrapped in a
Plugin class. In the following two
sections, I will briefly show both approaches. For a comprehensive guide on how
to use these approaches, refer to the Creating plugins section.
Standalone hook functions¶
Hook functions can be implemented as standalone functions by decorating them
repobee_hook() decorator. For example, if we
wanted to implement the
clone_task hook, we could do it like this:
import repobee_plug as plug @plug.repobee_hook def clone_task(): """Return a useless Task.""" return plug.Task(act=act) def act(path, api): return plug.Result( name="exampleplug", msg="This is a useless plugin!", status=plug.Status.SUCCESS, )
Hook functions in a plugin class¶
Wrapping hook implementations in a class inheriting from
Plugin is recommended way to write plugins for
RepoBee that are in any way complicated. A plugin class is instantiated exactly
once, and that instance then persists throughout the execution of one RepoBee
command, making it a convenient way to implement plugins that require command
line options or config values. The
class also performs some sanity checks when a subclass is defined to make sure
that all public functions have hook function names, which comes in handy if you
are in the habit of misspelling stuff (aren’t we all?). Doing it this way,
exampleplug.py would look like this:
import repobee_plug as plug PLUGIN_NAME = 'exampleplug' class ExamplePlugin(plug.Plugin): """Example plugin that implements the clone_task hook.""" def clone_task(self): """Return a useless Task.""" return plug.Task(act=self._act) def _act(self, path, api): return plug.Result( name="exampleplug", msg="This is a useless plugin!", status=plug.Status.SUCCESS, )
Note how the
clone_task function now does not have the @plug.repobee_hook
decorator, that we prefixed
act with an underscore to signify that it’s not
a public method (there is no hook function called
Plugin will raise if we forget the leading
underscore), and that the
self argument was added to all functions. For a
complete example of a plugin written with this approach, see the