Repository navigation
Plugin Infrastructure Discussion #52
Description
Activity
I have a slight preference for single namespace (mainly for allowing multiple plugins per file, which makes distribution easier). Now there is one thing that should be solved: how do we deal with (accidental) namespace clashes? As that might come up (users copy a new version of the plugin without deleting the old one etc...)
I think the solution is to error out if there is more than one plugin trying to register for the same name within the same kind of functionality. It looks like this is not done (yet) in the command plugins, but it's what I'm doing in #43. The error messages in there are already reasonably descriptive, I think:
(leading to messages like
CategoryCompilerRegistrationError: The category 'engine' has already been reserved by another plugin)(leading to messages like
RuntimeError: 'openmm' is already registered with engine)Now, the fact that there's some repeated behavior here (plugins register under some name or names and we need to watch for duplicates) suggests that this might be something that should be refactored into a more DRY solution. But that's a very low priority right now.
Note that technically we search the posix-style app dir (
.openpathsampling) but also do the formally correct thing of searching OS-specific app dirs. This may lead to more risk of duplication, so at some point it might be worth having a littledebug-pluginscommand to illustrate where each plugin is found.Also, I agree on using a single namespace. This wasn't possible before #48, so I had the idea of different namespaces for each plugin type in my head. Now that separate namespaces aren't required by technical limitations, I see no reason to add user/contributor confusion by requiring it.
I expect that the vast majority of installed plugins will be the built-in plugins anyway (i.e., the stuff that ships in this package), which means that the main reasons for multiple namespaces are unlikely to be relevant.
Closing this: with #43 and #54, we're definitely using the single namespace for all plugins (with plugin types differentiated by their types).
In #43 I added
paths_cli.utils.get_installed_plugins, which identifies all candidate plugins for a tuple ofplugin_types:openpathsampling-cli/paths_cli/utils.py
Lines 37 to 45 in f8ed965
We may change the directory for file-based plugins from
~/.openpathsampling/cli_plugins/to simply~/.openpathsampling/plugins/(or preferpluginswithcli_pluginsdeprecated) -- curious if there's any strong opinion on that. Namespace plugins go inpaths_cli_pluginsstill.
I'm close to finishing up #43 now, and I'd appreciate some thoughts on details of how add plugin support to OPS.
Here are the big ideas of the plugin infrastructure, no matter what:
We will use essentially the same plugin infrastructure for plugins providing multiple types of functionality: CLI subcommands are plugins, but so are tools to compile OPS objects from YAML/JSON, and so are (well technically, will be) components of the Wizard. This makes developing for the CLI extremely easy and means that contributions can be made without ever touching the core code. Different plugins types are distinguished by type: CLI commands are instances of
OPSCommandPlugin; plugins implementing support for compiling a new engine from YAML are instances ofEngineCompilerPlugin, etc. In the future, analysis tools may be developed based on the same plugin infrastructure.There are two ways of distributing plugins -- as files, or as namespace packages. Files are better for quick setups for yourself or a small group. To distribute to a wider audience (and have a more convenient mechanism for providing updates), use a namespace package.
My main question is: Should we use one location for all plugins, or a specific location for each plugin type? Command plugins can currently be installed in the namespace
paths_cli_pluginsor in the user's~/.openpathsampling/cli_plugins/directory. The question is whether that same namespace should be used for other plugins, like for the wizard or for theAdvantages for the single namespace:
Advantages for multiple namespaces:
~/.openpathsampling/cli_plugins/directory to be too cluttered to find the plugins they want.Note that the default plugins for each of these are in a different default namespace, so the default plugins already have the advantages of multiple namespaces.
@sroet : Any thoughts?