RFC/discuss get_missing_command fires too often

Robert Collins robertc at robertcollins.net
Sun Jul 12 22:42:33 BST 2009


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.

Thoughts?

-Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090713/4fb834dd/attachment.pgp 


More information about the bazaar mailing list