Make a better PluginManager

[mtomwing]

Ramblings

I don't believe Yapsy provides the kind of plugin framework that we need. This is primarily because it treats plugin classes as singletons but we need to have multiple instances (e.g. audio mixer sub-plugins). The current "solution" is to set an instance number attribute on the the plugin singleton and to have it reload its config. This is a hack.

A new PluginManager should:

• let plugins make use of the declarative configs from #373
• allow you to get an instance of a Plugin class that isn't a singleton
• provide an easier way for other plugins to get sub-plugins
• support the new use of Profile from #373

  Specific Requirements

  1. be able to load modules containing plugins at runtime (we don't need to reload them)
  2. be able to define new plugin types and enforce that plugins of those types implement specific interfaces
  3. when creating a plugin instance, the manager should automatically load the plugin's config (as used in #373)
  4. be able to query the manager for a plugins of a specific type
  5. should allow plugins to instantiate sub-plugins (in this case, the sub-plugin configs should be somehow "nested" inside the parent's config)

[Sephallia]

I was taking a closer look at Yapsy's documentation, and I found a line where it states, "It is often more useful to have the plugin manager behave like singleton, this functionality is provided by PluginManagerSingleton" (http://yapsy.sourceforge.net/PluginManager.html). If the primary issue is that plugin classes are singletons, this may not actually be an issue.

I haven't looked into what the other points say too much, but if the primary issue with Yapsy was that it "only uses Singletons and that's bad", then maybe instead of scrapping Yapsy, we can build off Yapsy?

To be absolutely honest, I haven't looked too much into Yapsy yet, so maybe Yapsy is also bad for other reasons. I'll keep looking into things.

Note: To clarify, this is nguyendp. (Sorry if having different handles gets confusing.)

[mtomwing]

Added some specific requirements. Hopefully this makes the end result more clear.

[Sephallia]

Project Proposal: https://docs.google.com/document/d/1ll7hGwjPzD6HLJ79WRGduJyUAprY4RU9REZznX8iVMQ/edit?usp=sharing

[Sephallia]

Referring to the specific requirements above... this is what I have accomplished.

(1) Is as far as I'm aware done or very close to being done. There are functions that examine directories to find files defining plugin classes. These functions can be called during runtime and not just in instantiation.

(2) Defining new plugin types is possible. At the moment, there isn't anything to enforce specific attribute implementations or anything of the sort.

(3) The create_plugin function is doing this. However, not all plugins classes currently defined have been translated to be compatible with this. Here is a list of the plugins that have been translated. AudioInput: alsasrc, autoaudiosrc, jackaudiosrc, audiotestsrc, pulsesrc AudioMixer: audiopassthrough, multiaudio Importer: csv_importer, rss_feedparser Output: audiofeedback, ogg_icecast

Translation is done rather loosely at the moment. These plugin files have been modified to... import the new plugin interface definition rather than the old one. Where appropriate, a Configuration Class has been defined as required by the standards we are moving to. And a CONFIG_CLASS member variable is created, being set to this Configuration Class or None as appropriate. I have also removed the load_config() function seeing as the Plugin will no longer be loading its own config, but rather the manager doing so.

(4) There is no "function" defined for this at the moment, but there is a dictionary that should make this pretty simple, unless there's more functionality required than I am aware.

(5) There is no start to this yet.

In terms of next steps to take, there are quite a few files in the project source code that depended on the old plugin.py (that's been removed) and now need manage.py instead. Correcting those to work correctly with the new manage.py seems like a good start. Potentially, some of the required functions should be written as stubs so the build completes as required even if the functionality is not yet there.

From there, I'd go about completing the five specific requirements defined above. I feel like like completing requirement (2) would be first. To ensure that all plugins are "shaped" correctly. Then translating the rest of the plugins to be compatible with the manager would be good. From there, (4) seems rather simple, and (5) would be the victory lap to this issue.