At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote:
but then we would be back to the problem mentioned about entry points: installing projects can implicitly add a plugin and activate it, and break existing applications that iterate over entry points without further configuration. So being able to disable plugins from the beginning seems important to me
So which are these apps that don't allow configuration, and which are the plugins that break them? Have the issues been reported so that the authors can fix them?
ISTM that the issue can only arise in cases where you are installing plugins to a *global* environment, rather than to an environment specific to the application.
In the case of setuptools, for example, it's expected that a project will use 'setup_requires' to identify the plugins it wishes to use, apart from any that were intentionally installed globally. (The requested plugins are then added to sys.path only for the duration of the setup script execution.)
Other applications have plugin directories where their plugins are to be installed, and still others have explicit configuration to enable named plugins.
Even in the worst-case scenario, where an app has no plugin configuration and no private plugin directory, you can still control plugin availability by installing plugins to the directory where the application's main script is located, or point PYTHONPATH to point to a directory you've chosen to hold the plugins of your choice.
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.
_______________________________________________ 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
