[RFC] Proposed plugins to bundle for 2.0

[Martin Pool]

2009/6/26 Ian Clatworthy <ian.clatworthy at internode.on.net>:
> Gioele Barabucci wrote:
>> Martin Pool wrote:
>>>> What do you think about renaming bzr-rebase to bzr-rewrite or
>>> Well, if it was merged, it wouldn't have a name at all, it would just
>>> be some commands within bzr.
>>
>> I thought that this was a proposal to "bundle" plugins with the default
>> installation of bzr, not a proposal to merge these commands in core bzr.
>>
>> Something akin to bzr-launchpad that is, IIRC, a separate plugin that
>> happens to be shipped in the default installation of bzr. Did I understand
>> it wrong?
>>
>
> You understood *my* intention correctly. I was still looking to keep the
> plugins as plugins, to document them as such and allow
> enabling/disabling (when that feature is available).
>
> It sounds like Martin was suggesting something more ambitious.
> Time-wise, I certainly can't see true integration of the functionality
> (vs plain plugin bundling) happening in time for 2.0.

I had in mind to merge them "completely" so that they are no longer
present as plugins: if they provide a command, provide it in the
normal way (lazy-loaded perhaps.)  There are a few factors, for and
against:

 * just putting them in the subdirectory is possibly less work than eg
registering the command in the usual way -- though I would say not
very much more, compared to looking over the code and agreeing that we
will merge it

 * Making them shipped plugins means they can be overridden by plugins
installed elsewhere; however if people already have copies of that
plugin installed that might just be confusing.  (Actually, people will
have similar problems when we move anything from a plugin into the
core, and perhaps we should handle it by eg blacklisting older plugin
versions.)

 * Keeping them as shipped plugins on the other hand does mean people
can install even newer or modified versions of those plugins to run
over the top.  On the other hand plugins can of course extend core
features.

 * Shipped plugins, are neither fish nor fowl, so cause some strange
cases like "selftest --no-plugins" not quite meaning "test only this
tree, not random things in my personal environment", and in particular
this causes some trouble discussed recently in make
dist-check-tarball.  Of course those bugs could be fixed (eg adding
--no-external-plugins) but I'm not sure the category is worthwhile
enough to keep supporting it.

 * Lazy-loaded registration is possibly somewhat faster than loading
several separate plugins.

 * Putting them as plugins does give a way for users to turn them off,
but this is probably better handled at a different level, making sure
they don't interfere if they're not used, because turning off the
plugin is a fairly blunt and unobvious tool, and also one for which
there's no current method other than removing the plugin.

 * Some plugins wrap and extend existing commands and this is less
clear than just having one command definition, maybe with more
modularity than at present.

 * In the long term these should be core features and I wouldn't want
the history that they started in plugins to persist unnecessarily.
Some of it is more historical accident than that the feature is really
something people want to independently control.

 * Core code may want to depend on them, eg in using diffstat
(currently a plugin) from bzr send (currently core)

Another thought - when we merge them, we ought to add a description of
the feature into the user documentation, or at least we should file a
bug at the time of merging saying that it needs to be documented.

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