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:

1. 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 of EngineCompilerPlugin, etc. In the future, analysis tools may be developed based on the same plugin infrastructure.

2. 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_plugins or 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 the

Advantages for the single namespace:

• Easier for developers (package a new engine and support for it in the CLI and in the wizard all in Python package)
• With New plugin infrastructure #48, it is possible to have more than one plugin in the same file, making it possible to add multiple pieces of functionality through one file-based plugin file, if all use the same namespace.
• Easier to tell users where to put things (especially for file-based; otherwise you say "well, put this file here, that file there...")

Advantages for multiple namespaces:

• There may be some performance advantages for multiple namespaces if users have lots of plugins. (Only search the namespace relevant to the current task.)
• If there are enough file-based plugins, a user might find their ~/.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?