Discussed changes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDAzXo0F+nu1YWqI0RAi2jAKCA2m4zmtAeFwmxh/zSFea1h2rqAQCfS8mO
x93oPNKKvIQqsrcbriwJeTc=
=pwX7
-----END PGP SIGNATURE-----