On 06/06/2017 08:48 AM, Andrei Stepanov wrote: > Hello. > > Currently Avocado Plugin System requires to implements all virtual > methods in plugins. Can we remove this restriction? RFE: Allow to > implement only necessary interfaces for plugins. Just skip their > invocation of absent methods in plugins? >
Some background information may be helpful here. As you most certainly know, Python[1] doesn't have any builtin solution for plugins/extensions. This is both good and bad. Initially, Avocado chose to write its own plugin/extension support code. Besides the extra code we had to maintain, it also had many shortcomings. So we went shopping for a better solution, and found/selected stevedore[2]. One of the stevedore suggestions, is to use Abstract Base Classes, which "provides a convenient way to document the API" and "keeps you honest"[3]. Since we benefited from its code, which is directly related to its accumulated experience, we decided to follow its advice. Additionally, this is clearly a trade off situation. It'd either require the complete interface to be present in the implementation (even if it does nothing) or to check the presence of each implementation method. We chose the former. IMO, it's hard to make a point when the proposal is to move the problem/complexity elsewhere. If we can simplify this, without adding other code elsewhere, I'm all in. > 1. This will allow as easily add new methods to existing Core Interfaces: > > http://avocado-framework.readthedocs.io/en/latest/api/core/avocado.core.html#module-avocado.core.plugin_interfaces > > Otherwise, any new interface extension to Core will force us to > rewrite __ALL__ plugins, which makes Avocado quite inflexible for > upgrading and for external plugins. > The plugin interfaces are currently *core*. It means that, in theory, there's no stability support in those interfaces and that users indeed have to pay attention to Avocado upgrades. In practice, there has been very little changes to those interfaces, and, if we feel the demand, we can consider making those interfaces stable in the future. Talking about interfaces and stability, that's exactly why we chose to define and require an interface. IMO, when you require a set of methods implemented, you minimize misbehavior from plugins on newer different Avocado versions. > 2. Allow for plugin-developers implement methods they require. > Yes, the current solution has indeed the requirement that all methods must exist, even if they do nothing. The reasons for those requirements have already been given. I honestly don't see the reason for a change of behavior here. But if other users/developers out there feel this is something that should be changed, this is the perfect time for them to speak up. > Thanks. > Thank you! [1] - Meaning the language, the CPython implementation and its standard library [2] - http://git.openstack.org/cgit/openstack/stevedore/ [3] - https://docs.openstack.org/developer/stevedore/tutorial/creating_plugins.html#creating-plugins -- Cleber Rosa [ Sr Software Engineer - Virtualization Team - Red Hat ] [ Avocado Test Framework - avocado-framework.github.io ] [ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
signature.asc
Description: OpenPGP digital signature