[Avocado-devel] Make optional interfaces implementation for plugin system.

[Cleber Rosa]

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  ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170606/0ba48405/attachment.sig>