Plugin Structure

All plugins must contain a manifest file named plugin.ini at their root that describes the plugin:

[plugin]
name = My Plugin
publisher = My Company
version = 0.0.1

[build]
input = ./src
output = ./my_plugin_v{version}.otp

[install]
class = MyPlugin

  • The plugin section provides the information displayed the OnTakt interface when managing the plugin.

  • The build section controls how the compiler will package the plugin:

    • input: all .py files in this directory will be compiled and bundled

    • output: the filename of the output bundle. {version} will be automatically replaced by the version specified in the plugin section. This should be unique, as it will become the internal ID of the plugin during installation.

  • The install section controls how OnTakt will load the plugin. It will look in the __init__.py file at the root of the package for a class named with the value of class. This class must extend OTPlugin as described below.

All plugins must contain a main class that extends the OTPlugin class. This inherits the following members:

class pytm4srv.plugins.exec.PluginExec

The base for plugin objects.

The PluginExec class is called OTPlugin inside the plugins’ namespaces.

app: Flask

The Flask object for the current application. This can be used to add URL routes and get values from the server configuration.

home: Path

The Path where this plugin has been unpacked for the current execution.

This contains the contents of the plugin archive (so the contents of the original source folder plus the manifest) as well as the log file.

This directory is deleted at shutdown and recreated each time the plugin is loaded.

logger: Logger

A Logger just for this plugin.

Lines written using this logger will show up under this plugin in the interface.

These are hooks than can be used to handle events in the plugin lifecycle:

Plugin lifecycle diagram