On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby <p...@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
_______________________________________________
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
