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.

When a plugin gets enabled, OctoPrint will also call the on_plugin_enabled() callback on its implementation (if it exists). Likewise, when a plugin gets disabled OctoPrint will call the on_plugin_disabled() callback on its implementation (again, if it exists).

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. For these plugins, disabling them will not trigger the respective callback at runtime as they will not actually be disabled right away but only marked as such so that they won’t even load during the required restart.

Note that uninstalling a plugin through the bundled Plugin Manager will make a plugin first get disabled and then unloaded, but only if it doesn’t require a restart. Plugins wishing to react to an uninstall through the Plugin Manager may implement on_plugin_pending_uninstall() (added in OctoPrint 1.8.0) which will always be called by the Plugin Manager, regardless of whether the plugin requires a restart of OctoPrint to be fully uninstalled or not. Please be aware that the Plugin Manager is not the only way to uninstall a plugin from the system, a user may also uninstall it manually through the command line, circumventing Plugin Manager completely.

The lifecycle of OctoPrint plugins.