This document is more for new ideas, not necessarily how plugins work at the moment.
Documentation
- need to write a document on how to create new plugins
- about plugin versioning
Order of operations:
1. Load plugins
2. Install any plugins in the plugins dict that aren't in the registry. If install succeeds then add the plugin to the registry.
3. Init plugins
bauble.pluginmgr.load():
Searches the plugins directory and populates the bauble.pluginmgr.plugins dictionary. Also checks the plugin dependencies and removes any plugins from either the plugins dict or registry if the plugin dependencies aren't met.
bauble.pluginmgr.init():
Initializes all the plugins in the plugin registry. Add all command handlers.
bauble.pluginmgr.install()
Installs plugins. If plugins_to_install="all" install all the plugins that are listed in the plugins dict but aren't in the registry.
What it should do?
The registry can only hold the classes and version of the classes that this database was created with, anything like 'enabled' would have to either go into the plugins themselves or into a separate global, file base registry.
Registration
- see the plugin/RegistryEntry class
- Removing a plugin shouldn't remove the plugins table, there should be a way to completely remove a plugin, data and all, possible have the plugin provide an uninstall method. Would have to ensure that uninstall() is only called when the plugin versions match
- is it possible to serialize arbitrary python code in a db or something similar that could be called when a plugin is removed
- need to be careful with conflicts on plugin installation, if a plugin is trying to create a table that already exists in the database then this could overwrite data…its up to the plugins to ensure that their names don't conflict
Dependencies
- All initialization and installation should be done in order of dependencies.
- Available plugins should be disabled if they're dependencies are not met.
Misc Ideas
- allow GPG signed plugins
- MD5 signed plugins
- The plugin directory should be customizable
- should plugins have a "type" maybe if we have a more specific interface wrap the generic plugin interface we would know the type of plugin, say the ToolPlugin interface wraps plugin interface so we know to add the ToolPlugin to the tool menu…this is similar to how the FormatterPlugin works, in this case the pluginmgr doesn't care about the type but the FormatterPlugin can check for custom ReportFormatters
- should be able to delete the plugins directory and still have the Bauble start correctly, this means we need to change the way the plugins are started so we should remove init.py from plugins/….at least there should be a message that says bauble can't be started because it can't find the plugins directory or there are not plugin available
- after checking all the plugins we should check each plugins list of dependencies and make sure that can we loaded, if not we should present an error and list the names of the plugins that could be loaded an why they couldn't, could control this with a PluginDependencyError exception
- need to be able to check if this is the plugins first run, might have to keep a plugin registry so we know what been initialized and what hasn't, probably have to have a setup or create method for newly created plugins
- and what about a path for upgrading tables from one version of a plugin to the next, versioning makes things start to get really complicated,
- SQLite doesn't allow column drop and alter, see http://erosson.com/migrate/docs/index.html
- allow plugin versioning and allow plugins to depends on specific version of other plugins
