On 31/07/2010 01:51, David Cournapeau wrote:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
<fuzzy...@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.
_______________________________________________
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
