[RFC] Automatic Plugin Suggestion

[Martin Albisetti]

On Feb 17, 2008 8:07 PM, Robert Collins <robertc at robertcollins.net> wrote:
> The provider returned should be usable already and not need a factory
> called on it. Just register an instance and not a type. (We try to avoid
> registries conflating registration with logic unless they are clearly
> the same thing).
>
> The method 'check_for_plugin' is confusingly named. Its looking for the
> plugin that provides a name, so find_plugin(name), or
> plugin_for_command(name) seem clearer to me.

Seems much cleaner. I'll work on this.

> I'm not sure that bzrlib.plugin is the right point to hook this; its
> nothing to do with loading plugins, and everything to do with hooking
> into command logic.

So this would go into commands.py?


> So, I'd say the core is just:
>
> for provider in command_providers_registry:
>     try:
>         plugin_name = provider.plugin_for_command(cmd_name)
>     except errors.NoPlugin:
>         pass
>     else:
>         raise CommandAvailableInPlugin(cmd_name, plugin_name, provider)
>
> making that error a subclass of two new errors - 'MissingPlugin' (for
> things a plugin can correct), and 'UnknownCommand' (to cleanup our
> current unknown command reporting), would be good for extensibility.

Gotcha, a bit more work but much cleaner.


> I think a global option to bzr '--auto-install' would be cool, then you
> can just repeat the command with --auto-install, and bzr will install
> the plugin and then run your command.
>
> But we probably need new core commands anyhow:
> cmd_install_plugin
> cmd_uninstall_plugin
>
> Because multiple providers can provide the same plugin, install
> plugin /may/ need something like:
> bzr install-plugin --command bisect
> (which will just install bisect from the first provider, using the same
> loop that command errors use). I think this is nice because the error
> can instruct people to run this exact command.
> And in future control directory errors can report
> "please run bzr install-plugin --format hg2" to get support for hg
> installed easily.

I'll add this to the spec for the next stage.


> I don't think any of the code you put in bzrlib.plugins should be merged
> to core - its just a lookup provider, and I expect that for most users
> this provider won't be desirable as it is not OS packaging system
> integrated.

The current code doesn't provide anything OS-specific, just the lookup
functions.
Is this asuming that each provider will have it's own DB?


Martin