Discussed changes

[Gustavo Niemeyer]

Hello Aaron,

> I like the intent of these changes, but I don't think they're quite
> right.

Ok, let's see..

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

Humm, interesting.

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

I see..

> 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

Yes, I like the idea of having bzrlib/commands, but even then,
having the concept of generic plugins around could still be useful.

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

That's how I've done in most of the softwares with subcommands I've
written. The concept works quite well.

> Modify register_command to always replace the previous command, and not
> gripe.

FWIW, this would fix the issue, even without touching anything else.

[...]
> 2. scan /usr/lib/python2.4/site-packages/bzrplugins for system-wide plugins
> 3. scan ~/.bzr.conf/plugins

That's exactly what's happening now, considering that there's no difference
in scanning 'bzrlib/plugins' or 'bzrplugins'.

Best regards,

-- 
Gustavo Niemeyer
http://niemeyer.net