Choose the order which Interface implementors will be executed

[daltonmatos]

Currently, plugnplay executes all implementors of a given interface in the order they were loaded. Issue #5 garantees that the same set of plugins will be loaded in the same order, every time.

This issue will add the ability to choose, per implementor, the order of its execution among all other implementors of the same interface.

The first ideia is to add an order atribute to the implementor class declaration, like this:

class MyImplementor(plugnplay.Plugin):
    implements = [MyInterface,]
    order = 10

This would tell plungplay that this implementor would be the 10th in the list of implementors of MyInterface. If two plugins declares the same order value, they would be ordered alphabetically.

if you want to give a high precence to a specific implementor you will be able to use order = plugnplay.FIRST, if you want to push an implementor to the end of the execution chain, you will be able to use order = plugnplay.LAST.

This will define a global order, that is, one given implementor would have the same order in every Interface it implements. This issue could evolve to implement a way of choosing an order per implemented Interface.

Something on these lines:

class MyImplementor(plugnplay.Plugin):
    implements = [(MyInterface, 10), (OtherInterface, 2),]

Or like this:

class MyImplementor(plugnplay.Plugin):
    implements = [(MyInterface, 10), (OtherInterface, 2),]
    MyInterface_order = 10
    OtherInterface_order = 2

But this could lead to a problem if some interface changes name and we forget to update the *_order line accordingly.

Anyway, just ideas. =)

[hugosenari]

More suggestions

'Use' unix startup solutions: systemv, systemd, upstart ideas:

Predefine some range 0 - n, where default is n
Redistribute this in well know system components

• 0 core
• 1 data
• 2 logic
• 3 ui
• 4 theme
• ...

Or distribute like H(n) from HTML

If you define some range you can predefine class corePlugin, dataPlugin, logicPlugin, guiPlugin, themePlugin that are nothing more then one of your suggestions predefined.

[daltonmatos]

This is an interesting ideia but I think that plugnplay, being a framework, shouldn't know about guiPlugin or dataPlugin. This sould be a knowledge of the application that is using plugnplay to provide some pluggable interfaces.

I think we could use the implementation of #11 to achieve this plugin types separation. Suppose we have this:

class OnePlugin(plugnplay.Plugin):
    implements = [MyInterface,]
    plugin_type = 'gui'

class OtherPlugin(plugnplay.Plugin):
    implements = [MyInterface,]
    plugin_type = 'core'

and so on. Assuming the issue #11 implemented the filter capability as a custom filter function (implemented by the application developer) we would be able to get only the core implementors of MyInterface with this:

core = MyInterface.implementors().filter(_core_implementors_filter)

and _core_implementors_filter could be like this:

def _core_implementors_filter(implementor):
    plugin_type = getattr(implementor, 'plugin_type')
    return plugin_type and plugin_type == 'core'

With this we could separate implementors of a given Interface by type. Note that the types were created by the app developer and plugnplay does not know what each type means, it just provides the tools so the developer will be able to acomplish the separation.

Here plugin_type and _core_implementors_filter are app specific.