2010/7/31 David Cournapeau <cournape at gmail.com>: > 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, > > David Hi David, I think the point Michael tries to make is to be able to activate (not register) some plugins for some projects. In this case, even if bzr system is used (and I agree, it's a really good system), how will you activate only some of them for your project? I don't think it is geared towards end users, much more towards developers (at least for the unittest plugins) in which case adding a .cfg file to your vcs is not much work to do ;) Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher
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