plugins vs builtins

[Martin Pool]

A couple of things came up recently (Parth's bzr-grep
<https://bugs.launchpad.net/bugs/503670> and Robert's bzr-plugin-info)
that could be made into either builtins or plugins.  Historically we
have just let the code's author put it wherever they want it, and
that's not a bad default, but perhaps we should have a conviction too.

I want Bazaar to be a good and usable tool by itself, not just a
framework for building a vcs, but also an extensible platform for
amazing plugins like foreign branches, pipelines, explorer, etc.

There are a few weaknesses at the moment that create a pressure for
things to be built in, but we can and should fix them, and in fact are
already fixing them:

 * Discovering that the right plugin exists: if you hope for 'bzr
grep' and don't find it, what do you do next?  The plugin guide and
bzr-plugin-info can help with this.

 * Ease of installing a plugin and keeping it up to date.

 * Plugin versioning and dependencies against trunk.

 * Packaging plugins, both on free Unix platforms and elsewhere.  Ian
is working on putting more into the Windows installer.  In the PPA we
need to make sure they're consistent.

 * Startup delays caused by plugins; can be addressed by import tariffs.

 * Systematic testing of plugins; can be addressed by Babune and
developers running their tests.

Ultimately there's no point avoiding these issues just for particular
plugins, unless we're going to get rid of plugins altogether, which
would be a big loss.  The more we think about enabling people to
implement say grep or plugin-info as a plugin, the better the
extension api will get.

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