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

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Mon Aug 2 17:53:42 CEST 2010


On 03:08 pm, merwok at netwok.org wrote:
>Le 02/08/2010 14:31, exarkun at twistedmatrix.com a écrit :
>>On 12:21 pm, mal at egenix.com wrote:
>>>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. [...]
>>
>>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.
>
>If namespace packages make it into Python, they would indeed solve a
>part of the problem in a nice, generic way.

I don't think this solves the problem.  Twisted's plugin system already 
uses namespace packages.  It helps slightly, by spreading out your 
plugins, but you can still end up with lots of plugins in a particular 
namespace.
>Regarding the performance
>issue, I wonder if functions in pkgutil or importlib could allow one to
>iterate over the plugins (i.e. submodules and subpackages of the
>namespace package) without actually loading then. We would get only
>their names though, not their description or any other information
>useful to decide to activate them or not.

The trick is to continue to provide enough information so that the code 
iterating over the data can make a correct decision.  It's not clear 
that names are enough.
>Maybe importing is the way to
>go, with a doc recommendation that people make their plugins 
>subpackages
>with an __init__ module containing only a docstring.
>
>Regards

Jean-Paul


More information about the Python-Dev mailing list