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

[P.J. Eby]

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.