PEP: Plugin management

As written in Envisage documentation, the applications we write need to change over time. We fix bugs, and we add, modify, and remove features. In other words, we spend most of our time either fixing or extending applications.

Sometimes we extend our applications by changing the actual code, sometimes we have other ad hoc extension mechanisms in place – a text file here, a directory of scripts there. As applications grow, they often end up with numerous places where they can be extended, but with a different extension mechanism at each one. This makes it hard for developers who want to extend the application to know :

  • where they can add extensions
  • how to add them


For concrete documentation on how to extend OpenAleaLab, see Plugins


Existing implementations

PkgResources / entry points

ETS Envisage / extension points

OpenAlea components

See How to declare OpenAlea components.

OpenAlea plugins

Plugin description

Variable or variables describing plugin. work in progress: Potential useful information:

  • classical meta info (name, icon, desc, authors, license, ...)
  • python/qt compatibility (does-it work with PyQt4 ? PySide ? Qt 5)
  • python compatibility (python 2 ? python 3 ?)
  • interfaces implemented by this widget
  • dependencies required

These information are used to filter search results. For example:

# Return all widgets
results = search('oalab.applet')

# Example of filter in basic query language

# Return all widget written by John Doe
results = search('oalab.applet', author='John Doe')

Depending of data description structure, we can imagine advanced query languages like SQL, SPARQL, or based on existing libraries

Possible approaches for plugin description:

Flat variables

name = 'HelpWidget'
authors = ['John Doe']


data = {
    'name' :
    'oalab': {
        'extensions': ['plantlab', 'tissuelab'],

Semantic web

data = """
@prefix dc: <>.
@prefix oa: <>

    dc:title "HelpWidget";
    dc:publisher "OpenAleaLab"