Stevedore - (Dynamic Code Patterns: Extending Your Applications with Plugins)

Dynamic Code Patterns: Extending Your Applications with Plugins      Download this deck  in here.

The ExtensionManager is created slightly differently from the DriverManager because it does not need to know in advance which plugin to load. It loads all of the plugins it finds.

    mgr = extension.ExtensionManager(
        namespace='stevedore.example.formatter',
        invoke_on_load=True,
        invoke_args=(parsed_args.width,),
    )

To call the plugins, use the map() method, passing a callable to be invoked for each extension. The format_data() function used withmap() in this example takes two arguments, the Extension and the data argument given to map().

    def format_data(ext, data):
        return (ext.name, ext.obj.format(data))

    results = mgr.map(format_data, data)

The Extension passed format_data() is a class defined by stevedore that wraps the plugin. It includes the name of the plugin, theEntryPoint returned by pkg_resources, and the plugin itself (the named object referenced by the plugin definition). Wheninvoke_on_load is true, the Extension will also have an obj attribute containing the value returned when the plugin was invoked.

map() returns a sequence of the values returned by the callback function. In this case, format_data() returns a tuple containing the extension name and the iterable that produces the text to print. As the results are processed, the name of each plugin is printed and then the formatted data.

    for name, result in results:
        print('Formatter: {0}'.format(name))
        for chunk in result:
            print(chunk, end='')
        print('')

Why Not Call Plugins Directly?

Using a separate callable argument to map(), rather than just invoking the plugin directly introduces a separation between your application code and the plugins. The benefits of this separation manifest in the application code design and in the plugin API design.

If map() called the plugin directly, each plugin would have to be a callable. That would mean a separate namespace for what is really just a method of the plugin. By using a separate callable argument, the plugin API does not need to match exactly any particular use case in the application. This frees you to create a finer-grained API, with more individual methods that can be called in different ways to achieve different goals.