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

P.J. Eby pje at telecommunity.com
Fri Jul 30 22:56:44 CEST 2010

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.

More information about the Python-Dev mailing list