(rfc) recommend installing a plugin when needed

[Martin Pool]

On 08/02/2008, Martin Albisetti <argentina at gmail.com> wrote:
> This is actually a late follow up on the IRC conversation about how to
> implement this.
>
> As I see it now, the plugin would be divided in the following:
>
> 1) Database of available plugins  (in the core?)
> 2) Code infrastructure to catch "not found" commands and suggest
> plugins (in the core)
> 3) Pluggable abstraction class to download and install plugins
> automagically  (in the core)
> 4) Default plugin to download plugins via checkouts (in the core?)
>
> All of those are necessary for this spec to work, although we could at
> a first stage, not include the automatic install infrastructure and
> just point users to URLs for the missing plugins.
>
> Now, the problems. The database of plugins will change
> semi-frequently. This means we have to provide some way of updating
> the local database. This also means we need to ship a DB with bzr
> itself, so we can recommend plugins out of the box.
> The idea would that there would be a plugin for each method of
> installing plugins (debs, rpm, etc), which would also have it's DB,
> overriding the default one, and falling back to the default if it
> doesn't provide it. This way we can make sure this feature works
> fairly well con all platforms.
> lifeless mentioned that shipping something like a plugin DB with the
> core isn't something we want, and that the DB itself should be
> provided by the install plugins, but we shouldn't ship the checkout
> plugin by default. This makes sense in some levels, but, on the other
> hand, makes the feature completely useless by default and delegates
> it's implementation to per-distro packaging or making the user install
> a plugin manually, which is what we are trying to avoid in the first
> place.

There is the intermediate level of "default plugins" in
bzrlib.plugins, shipped with bzr.  That would probably be an
appropriate point for the code that suggests plugins for missing
commands.

The db with bzr (which I imagine would be just a Python dict) does not
need to describe every installable command, just give pointers from
commands or help topics (or maybe disk formats) to the plugin names
that supply them, so updates to it could be fairly infrequent.

To map from the desired plugin name to the download location (branch,
deb, rpm), I would say we should use the network rather than storing
it in Bazaar.  For debs (and rpms?) I think we should know nothing
more than 'apt-get install bzr-plugin-$name'.  For installs from
branches, we can use Launchpad's branch directory to get the right
one.  (The branch need not be stored on Launchpad.)

I do want to point out that even if the user must install the plugin
manually, at least them so is better than nothing, as a first step.

-- 
Martin