On 03:08 pm, mer...@netwok.org wrote:
Le 02/08/2010 14:31, exar...@twistedmatrix.com a �crit :
On 12:21 pm, m...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
