[Python-Dev] proto-pep: plugin proposal (for unittest)

[P.J. Eby]

At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
>Automatic discoverability, a-la setuptools entry points, is not 
>without its problems though. Tarek outlines some of these in a more 
>recent blog post:

FWIW, it's not discovery that's the problem, but configuring *which* 
plugins you wish to have active.  Entry points support access by 
name, and it's up to the application using them to decide *which* ones to load.

The underlying idea is that entry points expose a hook; it's up to 
the app to decide which ones it should actually import and use.  An 
application also can list the available plugins and ask the user, 
etc.    (For example, setuptools only loads "setup() argument" entry 
points for specified arguments, and command entry points only for the 
commands a user explicitly invokes.)

IOW, entry points provide access to plugins, not policy or 
configuration for *which* plugins you wish to use.  This was an 
intentional decision since applications vary widely in what sort of 
configuration mechanism they use.  In the simplest cases (e.g. 
single-app environments like Chandler), simply making the plugin 
available on sys.path (e.g. via a special plugins directory) is 
configuration enough.  In more complex use cases, an app might have 
to import plugins in order to get more information about them.