The memri [pod](https://gitlab.memri.io/memri/pod) uses a plugin system to add features to the backend memri backend. Plugins can import your data (importers), change your data (indexers), or call other serivces. Users can define their own plugins to add new behaviour to their memri app. Let's use the following plugin as an example of how we can start plugins.
print(f"logging in with account {account.identifier} and password {account.secret}")
defadd_to_schema(self,client):
client.add_to_schema(MyItem("my name",10))
```
%% Cell type:code id: tags:
``` python
# hide
MyPlugin()
```
%% Output
MyPlugin (#None)
%% Cell type:markdown id: tags:
```python
classMyItem(Item):
properties=Item.properties+["name","age"]
edges=Item.edges
def__init__(self,name=None,age=None,**kwargs):
super().__init__(**kwargs)
self.name=name
self.age=age
classMyPlugin(PluginBase):
""""""
properties=PluginBase.properties
edges=PluginBase.edges
def__init__(self,**kwargs):
super().__init__(**kwargs)
defrun(self,client):
print("running")
self.login()
client.create(MyItem("some person",20))
deflogin(self):
account=self.pluginRun.account[0]
print(f"logging in with account {account.identifier} and password {account.secret}")
defadd_to_schema(self,client):
client.add_to_schema(MyItem("my name",10))
```
%% Cell type:markdown id: tags:
Memri plugins need to define at least 2 methods: `.run()` and `.add_to_schema()`. `.run()` defines the logic of the plugin. `.add_to_schema()` defines the schema for the plugin in the pod. Note that currently, `add_to_schema` requires all item to **have all properties defined that are used in the plugin**. In the future, we might replace add_to_schema, to be done automatically, based on a declarative schema defined in the plugin.
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.
%% Cell type:code id: tags:
``` python
# export
# hide
@call_parse
defstore_keys(path:Param("path to store the keys",str)=DEFAULT_POD_KEY_PATH,
database_key:Param("Database key of the pod",str)=None,
owner_key:Param("Owner key of the pod",str)=None):
logging in with account myusername and password mypassword
%% Cell type:markdown id: tags:
> Note: The data that is created here should be in the pod in order for this to work
%% Cell type:markdown id: tags:
## Run from pod
%% Cell type:markdown id: tags:
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 "installed" within the Pod environemnt (e.g. `docker build -t pymemri .` for this repo) in order to start it.**
%% Cell type:markdown id: tags:

%% Cell type:code id: tags:
``` python
# export
fromfastcore.scriptimportcall_parse,Param
importos
@call_parse
defsimulate_run_plugin_from_frontend(pod_full_address:Param("The pod full address",str)=DEFAULT_POD_ADDRESS,
database_key:Param("Database key of the pod",str)=None,
owner_key:Param("Owner key of the pod",str)=None,
plugin_id:Param("Pod ID of the plugin",str)=None,
container:Param("Pod container to run frod",str)=None,