RFC/discuss get_missing_command fires too often

Martin Pool mbp at sourcefrog.net
Mon Jul 13 02:39:11 BST 2009


2009/7/13 Martin Pool <mbp at sourcefrog.net>:
>> I don't think we gain a lot of protection with the current system, but
>> perhaps it is worth keeping? If its worth keeping, then I propose to
>> tweak the get_cmd_object function to support a parameter controlling
>> whether get_missing_command fires.
>
> What would that option actually mean?  It's not quite "give me only
> builtin commands."
>
> If it means "give me a command object but don't load it's
> implementation" maybe that's better done by the returned command
> object being some kind of skeleton.
>
> This actually makes me wonder if the difference between "get_command"
> and "get_missing_command" really makes sense.

Re-reading the previous thread I can see there is a difference of
intent, but it should be explained much better in the hook
documentation.  get_command is to find the command, whereas
get_missing_command is a UI-oriented hook that can interact with the
user (as bzr-guess does) or do other expensive or impure operations to
determine which command to use.  Therefore I think it is reasonable
for callers of get_command to say whether they want that or not.

> 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?
-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list