plugins vs builtins

[Parth Malwankar]

On Wed, Mar 3, 2010 at 12:00 PM, Martin Pool <mbp at canonical.com> wrote:
> 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:
>

I feel the decision of plugin vs builtin should be based on the number
of people that use/need a command(s). Bugs on launchpad marked
as "it affects me" is probably good number to go with but I am not sure
how many users bother to mark the bugs.

If there were a download count on launchpad, that could be useful
but that would require that we have a mechanism to make users
aware that a plugin exists. I think bzr-plugin-info would suit this well.

Maybe plugins that meet a certain criteria (X installation or X votes)
can be moved in bzr as prepacked plugins (./bzrlib/plugins ??).
Prepackaged plugins should probably be version controlled outside bzr
and a certain version pulled in during packaging. I can't really think
of a good criteria to differentiate between prepacked plugins vs builtin.

One advantage of keeping something as a plugin as you mentioned
in bug #503670[1] is that a new feature could also be available
for older versions of bzr.

For bzr-grep as the question of plugin-vs-builtin came up I was thinking
if it made sense to continue to maintain the plugin line, even if it became
a builtin, so users of 2.0 and 2.1 would be able to get a grep command.

[1] https://bugs.launchpad.net/bzr/+bug/503670/comments/12

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

One difference between plugin-vs-builtin comes to mind is that in case
of a builtin, the builtin is always maintained and enhanced by the
bzr experts. It may so happen that a plugin may be abandoned over time
by the original author. There should probably be a way for users to
differentiate between plugins and "blessed" plugins. The user should
be able to be sure that its being maintained and its quality is blessed
and won't do anything funny due to subtle bugs.

Regards,
Parth

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