[Python-Dev] proto-pep: plugin proposal (for unittest) (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Sat Jul 31 13:46:05 CEST 2010

On 31/07/2010 01:51, David Cournapeau wrote:

On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

For those of you who found this document perhaps just a little bit too long, I've written up a much shorter intro to the plugin system (including how to get the prototype) on my blog:

http://www.voidspace.org.uk/python/weblog/archd720100724.shtml#e1186 This looks nice and simple, but I am a bit worried about the configuration file for registration. My experience is that end users don't like editing files much. I understand that may be considered as bikesheding, but have you considered a system analog to bzr instead ? A plugin is a directory somewhere, which means that disabling it is just removing a directory. In my experience, it is more reliable from a user POV than e.g. the hg way of doing things. The plugin system of bzr is one of the thing that I still consider the best in its category, even though I stopped using bzr for quite some time. The registration was incredibly robust and easy to use from a user and developer POV, Definitely not bikeshedding, a useful suggestion David.

As Matthieu says in his reply, individual projects need to be able to enable (and configure) individual plugins that their tests depend on - potentially even shipping the plugin with the project.

The other side of this is generally useful plugins that developers may want to have permanently active (like the debugger plugin), so that it is always available to them (via a command line switch).

The proposed system allows this with a user configuration file plus a per-project configuration file. I take your point about users not liking configuration files though. I've looked a little bit at the bzr plugin system and I like the plugins subcommand.

If PEP 376 goes ahead then we could keep the user plugin and use the PEP 376 metadata, in concert with a user config file, to discover all plugins available. A plugins subcommand could then activate / deactivate individual plugins by editing (or creating) the config file for the user. This could be bolted on top of the config file solution once PEP 376 is in place. It doesn't handle the problem of configuring plugins. So long as metadata is available about what configuration options plugins have (through a plugins API) then the plugins subcommand could also handle configuration.

Installation of plugins would still be done through the standard distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would be fine with this.)

Another possibility would be to have a zero-config plugin installation solution as well as the config files. Create a plugins directory (in the user home directory?) and automatically activate plugins in this directory. This violates TOOWTDI though. As it happens adding a plugin directory would be easy to implement as a plugin...

All the best,

Michael

David

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

More information about the Python-Dev mailing list