At 04:37 PM 7/30/2010 +0200, Tarek Ziadé 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

On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw <barry@python.org> wrote: .. 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).