Allow Decorators to extend gatherPluginInfo
A fat-free DIY Python plugin management toolkit.
Brought to you by:
tibonihoo
Menu
▾
▴
#3 Allow Decorators to extend gatherPluginInfo
Decorator never see the call from the manager to gatherPuginInfo (as to do this they would have to subclass the manager itself rather than a decroatror) so they cant link in here without monkey-patching plugin manager.
This means that uses of Yapsy which use extended Info classes can't easily read there data and locatePlugins time - also they can't use the same instance of configParser to read data from the infofile.
Arguable the same problem exists for all the accessor/mutators in PluginManager - as any method that plugin manager calls on itself is not indirected through the decorator chain. Although it is more difficult to find a use-case for changing these.
Related
Discussion
Anonymous
I guess this question calls for several anwsers.
First of all an answer on the broadest question on accessors/mutators: these methods are "not indirected through the decorators chain" on purpose. So the limitation you're pointing at exists but is part of the design: the only methods that can be safely modifed are locatePlugin and loadPlugin, others may be used but not reimplemented.
About this design "problem": I'm trying to find a way to forbid the reimplementation of other methods (or at least to make it as clear as possible that they should not be reimplemented). For some of them I might even use the "__method" trick of Python.
The main reason for the limitation is to avoid surprises in the chaining of decorators. I'm not 100% convinced it's the better way to do it, but I think an improvement would require more than just chaining the methods through the decoration chain. So it's not going to happen in Yapsy1.x, but might be in the scope of a Yapsy2.x along with a big rework on the whole architecture.
Concerning the "gatherPluginInfo" problem, the short terrm solution, would be one of the following:
* if possible it could be an attribute of the plugin class (not the info file)
* if the first solution is not possible but the information is short (like one variable only) we can change the basic plugin info representation and add it to the basic PluginInfo class
* if the info is more complex, then why not set it in a specific section of the plugin info file and use a new instance of config parser, I don't think this will hurt performances except maybe when loading thounands of plugins. (NB: the path to the plgin info file is available in the candidate description).
A more elegant solution would be for the PluginInfo class to mark its own config parser or at least a mapping (sectionName,varName)->attribute, since the plugin info class can already be customized.
Ok, I don't want the plugin_oject itself to have the extra data - I wasnt to use this a the decision about whether to load the plugin or not.
The candidate filename is never passed to the Info object's init method , yes it's available in the PlugnTuple but that means I need a decorator to handle my extra data as well as decarators for other things. it just seems a bit messy.
I'll get my current design reworking online at bitbucket later- they need a bit of tidying but they 'll give you and ideal of were I'm goign .
But it basic terms , I'm thinking about rolling the pluginTuple into the plugin_info object and then use the same configparser in here , and a method chain to gather all the non core info.
This may indeed be yapsy 2.x - since keeping it neat and backward compatible doesn't look easy.
I'm always dubious about not allowing the access/mutator to be ovverriden - IMO it's a serious problem in yapsy.
PluginManager should be querying the plugin database which is managed by it in concert with the decorators. That Database may need to consist of data from unconventional sources.
For instance I can conceive of system which store it plugin in a SQL database or a networked resource.
I'm not sure I got everything but basically (just to check) you want the "candidate" tuple to be fed to the plugin_info's init method and the configparser to be called within this init method (which would make it possible to customize the plugin info class) ?
If so this is nice, but we should take a care of a problem: what if two chained decorators register incompatible plugin info classes (note in the way the problem is already there, but I don't necessarily want to make it worse)
The serious problem with yapsy (and I agree it is serious) is that the inital idea was to make it easy to add functionalities by decorators. However the functionalities to be added are not "orthogonal" (which would call for an implenetation with mixins instead of decorators) but they all consist in customising the same steps of the plugin locate/load. To a certain extent I should have looked at a strategies pattern I guess, but the decoration mechanism makes it more natural to wrap the current locate and load methods.
However this was done with the assumption that people would prefer chaining (simple) decorators instead of reimplementing complexe feature by inheritence.
The call for being able to reimplement each and every method of the "core" plugin manager, doesn't play well with decoration (though it does with reimplementation by inheristance).
As for your idea about the plugin manager managing a database where plugins are waiting to be loaded/unloaded, again it's a very interesting idea (seriously !) but yaspy1.x is meant to provide a database of loaded plugins, waiting to be activated/deactivated.
Hence an additional question: where do you draw the line -- in your application -- between loading and activating a plugin ?
Relevant url for bitbucket
http://bitbucket.org/rgammans/yapsy-mysterymachine-edition.
OK, I've looked at the repository. Feeding the tuple directory to the plugininfo class seems a better way to do indeed.
Now I d'ont really want to let you have the somehow dirty "newinit" method in your code, so i'll try to decide on wether:
* include this as an api break in yapsy1.8 (there are probably very few users of yapsy and even fewer that tweak the pluginInfo class, so it mioght be ok)
* open right away a 2.x branch where we could put your improvement
Whatever the decision will be, feel free not to keep backward compatibility on your version of the sources (on bitbuckets), this backward compatility thing is certainly very important in some places but it often does more harm than good especially on code that need a good clean up anyway.
That sound senssible I didn't like the newinit approach myself either.
After looking a little deeper into yapsy (and re-writting a big part of the doc), I think the plugin gathering process should be be modified by decorators: at least not the PluginManagerDecrators as defined in yapsy.
To do this kind of thing: it's better to change the plugin manager.
For future evolutions, it would be even better to find a clean and simpler way to do this kind of changes, which might require implementing the core plugin manager with strategies or something like, that. At that time, the suggestions that were made on this bug report will certainly be highly useful !
Thanks for reporting.