RFC/discuss get_missing_command fires too often

[Martin Pool]

2009/7/13 Robert Collins <robertc at robertcollins.net>:
> On Mon, 2009-07-13 at 11:39 +1000, Martin Pool wrote:
>>
>> > I think it would be better to modify the default command
>> > suppliers (plugin_cmds and the buitins scanner) inside bzrlib to
>> instead
>> > note whether the particular registration has requested decoration at
>> > command object creation time. As our built in suppliers are ordered
>> and
>> > the first things registered we can reasonably expect this to be
>> robust.
>>
>> What do you mean by that?
>
> I'll put a patch together this week to improve the get_missing_command
> docs.
>
> In the above paragraph I mean that _get_plugin_command should check
> whether an existing command had been found (command lookup works as a
> pipeline). If one was found and there is a registered plugin command of
> the same name, it should *at that point* perform the policy check for
> 'are we overriding' - rather than doing it at the 'register_command'
> step.

I wonder if it should pass the previously-found, typically builtin
command to the constructor of the plugin command, so that it can
either complain or decorate it.  That would be a way around the
problem of plugins, which often want to do decoration, forcing the
builtin commands to be loaded.  Or maybe there's already some solution
for this?

-- 
Martin <http://launchpad.net/~mbp/>