--- title: Plugins keywords: fastai sidebar: home_sidebar nb_path: "nbs/plugin.pluginbase.ipynb" ---
PluginBase is the base class of all Pymemri plugins. You can either build your plugin from scratch, or start with one of our Plugins Templates.
All inheriting classes should implement:
PluginBase.run, which implements the logic of the pluginPluginBase.add_to_schema, for adding plugin specific item types to the PodNote that both the pluginRun and client arguments are mandatory for running a plugin. When using the run_plugin CLI, these are handled for you. For local development and testing, a plugin can be initialized with just a client, which results in a RuntimeWarning.
Let's use the following plugin as an example of how we can define and run plugins.
from pymemri.pod.client import Dog
class ExamplePlugin(PluginBase):
def __init__(self, dog_name: str = "Bob", **kwargs):
super().__init__(**kwargs)
self.dog_name = dog_name
def run(self):
print("Started plugin run...")
dog = Dog(self.dog_name, 10)
self.client.create(dog)
print("Run success!")
def add_to_schema(self):
self.client.add_to_schema(Dog)
Many plugins use authentication for external services that require passwords or oauth authentication. Pymemri implements some common cases, see OAuthAuthenticator or PasswordAuthenticator.
Plugins can be started using the pymemri run_plugin or simulate_run_plugin_from_frontend CLI. With run_plugin the plugin is invoked directly by spawning a new python process, while simulate_run_plugin_from_frontend requests the pod to spawn a new process, docker container, or kubernetes container, which in calls run_plugin (for more info see simulate_run_plugin_from_frontend. When using run_plugin, you can either pass your run arguments as parameters, or set them as environment variables. If both are set, the CLI will use the passed arguments.
To start a plugin on your local machine, you can use the CLI. This will create a client for you, initialize the plugin, and run the code defined in the run method of your plugin.
!run_plugin --metadata "../example_plugin.json"
Often, plugins require some configuration for a run. For example, our ExamplePlugin has a dog_name argument, which could be different for different runs.
Pymemri handles plugin configuration by passing a dictionary of configuration values to the __init__ method of the plugin. A possible configuration for the ExamplePlugin could be:
{"dog_name": "Alice"}
Configuration can be passed to the run_plugin CLI in two ways:
PluginRun item, as config property. This value should be a json serialized dictionary, which is deserialized and passed to the plugin by the CLIrun_plugin as a --config_file argument. If this option is used, the config property from the PluginRun is ignored.In production, we start plugins by making an API call to the pod, which in turn creates an environment for the plugin and starts it using docker containers, kubernetes containers or a shell script. We can start this process using the simulate_run_plugin_from_frontend CLI. Note that when using docker, provided container name should be built within the Pod environment (e.g. docker build -t pymemri . for this repo), or available on the memri gitlab container repository.
!simulate_run_plugin_from_frontend --metadata "../example_plugin.json"