[Python-Dev] PEP 376 proposed changes for basic plugins support

[exarkun at twistedmatrix.com]

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 entry_points.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