[Python-Dev] PEP 376 proposed changes for basic plugins support (original) (raw)

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Mon Aug 2 14:31:45 CEST 2010

On 12:21 pm, mal at egenix.com wrote:

Tarek Ziadé wrote:

On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <pje at telecommunity.com> wrote: ..

So without specific examples of why this is a problem, it's hard to see why a special Python-specific set of configuration files is needed to resolve it, vs. say, encouraging application authors to use the available alternatives for doing plugin directories, config files, etc. I don't have a specific example in mind, and I must admit that if an application does the right thing (provide the right configuration file), this activate feature is not useful at all. So it seems to be a bad idea. I propose that we drop the PLUGINS file idea and we add a new metadata field called Provides-Plugin in PEP 345, which will contain the info I've described minus the state field. This will allow us to expose plugins at PyPI. IOW, have entry points like setuptools provides, but in a metadata field instead of a entrypoints.txt file. Do we really need to make Python packaging even more complicated by adding support for application-specific plugin mechanisms ? Packages can already work as application plugins by simply defining a plugins namespace package and then placing the plugin packages into that namespace. See Zope for an example of how well this simply mechanism works out in practice: it simply scans the "Products" namespace for sub-packages and then loads each sub-package it finds to have it register itself with Zope.

This is also roughly how Twisted's plugin system works. One drawback, though, is that it means potentially executing a large amount of Python in order to load plugins. This can build up to a significant performance issue as more and more plugins are installed.

Jean-Paul

More information about the Python-Dev mailing list