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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4