RFC/discuss get_missing_command fires too often

[Martin Pool]

2009/7/13 Robert Collins <robertc at robertcollins.net>:
> Commands.hooks['get_missing_command'] currently fires whenever a command
> is not found. However some parts of the command infrastructure itself
> would benefit by being able to probe without triggering a
> missing-lookup. In particular things that want to generate an error at
> registration time if a given name is already registered.
>
> Now, we want to be more lazy about work performed during startup, so
> checking that nothing provides a given name isn't really all that
> desirable. 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.
>
> This would:
>  - move errors about duplicate command names from startup to execution -
>   notable 'bzr FOO' where FOO is duplicated, and 'bzr help commands' or
>   'bzr help FOO'.
>
> 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.

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