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.
