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/arch_d7_2010_07_24.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.
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