General Concepts

OctoPrint’s plugins are Python Packages which in their top-level module define a bunch of control properties defining metadata (like name, version etc of the plugin) as well as information on how to initialize the plugin and into what parts of the system the plugin will actually plug in to perform its job.

There are three types of ways a plugin might attach itself to the system, through so called mixin implementations, by attaching itself to specified hook, by offering helper functionality to be used by other plugins or by providing settings overlays.

Plugin mixin implementations will get a bunch of properties injected by OctoPrint plugin system to help them work.

Lifecycle

There are three sources of installed plugins that OctoPrint will check during start up:

• its own octoprint/plugins folder (this is where the bundled plugins reside),

• the plugins folder in its configuration directory (e.g. ~/.octoprint/plugins on Linux),

• any Python packages registered for the entry point octoprint.plugin.

Each plugin that OctoPrint finds it will first load, then enable. On enabling a plugin, OctoPrint will register its declared hook handlers and helpers, apply any settings overlays, inject the required properties into its declared mixin implementation and register those as well.

On disabling a plugin, its hook handlers, helpers, mixin implementations and settings overlays will be de-registered again.

Some plugin types require a reload of the frontend or a restart of OctoPrint for enabling/disabling them. You can recognize such plugins by their implementations implementing ReloadNeedingPlugin or RestartNeedingPlugin or providing handlers for one of the hooks marked correspondingly.