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

P.J. Eby pje at telecommunity.com
Fri Jul 30 23:04:19 CEST 2010

At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote:

On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw <barry at python.org> wrote: .. > * Registration - How do third party plugins declare themselves to exist, and > be enabled? Part of this seems to me to include interface declarations > too. Is installation of the plugin enough to register it? How do end users > enable and disable plugins that me be registered on their system? How do > plugins describe themselves (provide short and log descriptions, declare > options, hook into command line interfaces, etc.)? > > * Installation - How are plugins installed on the system? Do they have to > appear in a special directory on the file system? Do they need special > setup.py magic to write extra files? Do they need to live in a pre-defined > namespace?

FWIW We are thinking about adding in distutils2 a system quite similar to the entry points setuptools has, but with extra abilities for the end user : - activate / deactivate plugins without having to remove the project that added them - configure globally if plugins are implicitely activated or not -- and maybe allow the distutils2 installer to ask the user when a plugin is detected if he wants it activate or not - provide a tool to browse them

Note, by the way, that none of these are mutually exclusive to the entry point mechanism; it is simply up to an application developer to decide which of those features he/she wishes to provide. A library that provides common implementations of such features on top of entry points would be a good idea.

pkg_resources already supplies one such tool, btw: the "find_plugins()" API for locating projects in one or more "plugin directories" that could be added to sys.path to provide plugins for an application. It's then up to the application to filter this list further (e.g. via its own configuration).

More information about the Python-Dev mailing list