Discussed changes

[John A Meinel]

Aaron Bentley wrote:
> Martin Pool wrote:
>
>>>On 8/17/05, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
>>>
>>>
>>>>Martin, I've performed the small changes in bzr we've discussed
>>>>about, and have put it online at:
>>>>
>>>
>>>Thanks, this is merged in.
>>>
>
>
> I like the intent of these changes, but I don't think they're quite right.
>
> The problem is that a user may have installed the plugin locally.  In
> this case, I believe the bzrlib/plugin version should be overridden.
> Just like with normal commands, in other words.
>
> I currently have *my* version of the changeset plugin installed, and
> that's what I want to use.  I don't want register_command griping at me.
>
> Martin, you recently wrote that you'd like to separate the Command
> infrastructure and the actual commands.  I'd like to suggest doing it
> this way:
>
> Instead of bzrlib/plugins, introduce bzrlib/commands.  Split
> bzrlib/commands.py into bzrlib/cmdstructure.py and
> bzrlib/commands/builtins.py.  New commands can each have their own file.
>  This is how I structured Fai and BaZing, and I still think it's a good
> approach.
>
> Modify register_command to always replace the previous command, and not
> gripe.
> 1. scan bzrlib/commands
> 2. scan /usr/lib/python2.4/site-packages/bzrplugins for system-wide plugins
> 3. scan ~/.bzr.conf/plugins
>
> This allows commands to extend the behavior of the previously-registered
> command, whether it came with bzr or was, itself, a mod.
>
> The first scan should happen even if plugins are disabled.
>
> Aaron

I agree with Aaron that site-wide plugins should probably be overridden
by local plugins.
Though my original design was that if you want "site-wide" plugins, just
put them into your BZR_PLUGIN_PATH. But since we have "bzr.conf/plugins"
I suppose we can have $BZR/bzrlib/plugins as well.
We just need to rethink the system of plugin overloading. Oh, and I
would like a way to *disable* the site-wide plugin directory. (Right now
I can disable the local one by creating an empty BZR_PLUGIN_PATH).

My suggestion is to have BZR_PLUGIN_PATH act more like the real path,
where the first entry found is used, and all others are ignored. The
warning was more of a debugging thing so that people would understand
why their plugin may not be loaded.
And then I would have BZR_PLUGIN_PATH changed so that the default path
is "~/.bzr.conf/plugins:$BZRLIB/plugins"

So that by default personal plugins take precedence, and then site-wide
plugins. And if someone wants to change what gets loaded, they can just
use the environment variable.

I would also consider getting rid of the automatic nature of plugins,
and switch to using a dictionary of command-name => function.
I was realizing that if you use plugins to implement hooks, you might
want multiple levels. So each level could grab the old "commit"
function, replace it with it's own function, and then call the original.
This would let you chain multiple overloads. Right now we really only
support 1 overload.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050817/48b1d4e5/attachment.pgp