Python plugin architecture explored
This was taken from my RoundToit project notes, where I have put several things that I find interesting. I just realized that I should put it in my tips as well.
Looking at abstract classes article (abc- Abstract Base Classes) gave me some ideas on how to handle the registering of classes for the plugins - don't need to use abstract base classes, but it had some good information:
In the section called Implementation Through Subclassing it has some code that shows how to do this. It starts with the text:
A side-effect of using direct subclassing is it is possible to find all of the implementations of your plugin by asking the base class for the list of known classes derived from it (this is not an abc feature, all classes can do this).
In the articles by Dr. Andre Roberge blog (not sure which one, as the link in the article above is invalid), he writes about how he did a plug-in for his tool called crunchy. He show several ways of doing this
- Plugins - part 1: the application
- Plugins - part 2: modularization
- Plugins - part 3: Simple class-based plugin
- Plugins - part 4: Crunchy-style plugin
- Plugins - part 5: Activation and Deactivation
- Plugins - part 6: setuptools based approach
- source code - py-fun
- downloaded code is in the
research/plugin-examples
directory of therndToit2
project
I want to use what I have with what is above to create a better plugin for the stuff that I use.