[RFC] Automatic Plugin Suggestion

[Robert Collins]

On Sat, 2008-02-16 at 04:00 -0200, Martin Albisetti wrote:
> This initial bit is just for checking if the command the user is
> trying to run exists on as a "officially approved plugin", and will
> output some helpful text to orientate the user on how to install it.
> Eventually, it will tell the user the command it needs to run in order
> to automagically install it, but that's phase 2 at the very least.
> 
> So, a little bit of history on my train of thought on the code
> implementation (most of it was a back and forth of ideas with
> Guillermo Gonzalez).
> Initially I was going to allow/make each plugin offer it's own DB of
> plugins, forcing them to reimplement the code basis for checking the
> availability of a command and handling it correctly. This would
> duplicate too much code and make the "official plugins" DB be
> type-of-installer specific (debs, rpms, etc).
> It seemed like too much of a hassle to maintain for each plugin a DB
> and would make the term "official plugin" be much more blurry since it
> would depend on each installer.
> The actual idea of a plugin being official or not I think is a great
> opportunity to incentive people to keep their code basis as clean and
> bug-less as possible, and adhere to a list of requisites of quality
> standards we would define.
> 
> What I'm attaching here is an attempt at the infrastructure to check
> for the availability of a command within a plugin (leaving it hookable
> if someone else wants to override it for some reason), and does not
> know anything about other possible installers since we really don't
> need to know at this point who/how it can installed.
> 
> I included some basic blackbox tests in it, but I'm out of ideas on
> what other tests I can add.
> 
> It also needs some PEP8 love, but I'd like to know if I'm on the right
> path before I put more work into this code.

Some notes:

+
+    # look for plugins that provide this command but aren't installed
+    provider = plugin.providers_registry.get()
+    if not provider is None:
+        plugin_cmd =  provider().check_for_plugin(cmd_name)
+        if not plugin_cmd is None:
+            return plugin_cmd

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.

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.

Also raise an error rather than returning None.

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.

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 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.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080218/eea69e60/attachment.pgp