RFC: shipping external-tree plugins

Colin D Bennett colin at gibibit.com
Thu Jul 31 07:43:56 BST 2008


On Thu, 31 Jul 2008 14:51:46 +1000
Robert Collins <robertc at robertcollins.net> wrote:

> On Thu, 2008-07-31 at 13:23 +0900, Stephen J. Turnbull wrote:
> > Robert Collins writes:
> > 
> >  > This is a possible on Debian; but we seem to have a consistent
> >  > history of users not knowing what is available - thats the real
> >  > bug we need to solve.
> > 
> > Has use of eggs or distutils format packages for the plugins and a
> > registry (presumably on launchpad) of available plugins a la PyPI
> > been considered?
> 
> Yes - many threads have been had.
> 
> My mental model here is:
>  - replacing packaging systems is bad - eggs etc are a problem 
>  - having a suggestion mechanism is desirable - see the 
>    plugin_info plugin which can generate the input data for an
> automated registry, and Martin Albisetti's work for suggesting
> plugins when a missing command is requested
>  - we should start publishing a registry of these that can be
> consulted, and hook into the local packaging system where possible
>  - but even doing so will still cause hiccups for users that are
> offline when they try a command from a plugin, or for which complex
>    dependencies are not available
> 
> which is why I prefer to get the issues all addressed up front by the
> packagers by presenting a single composite ;)
> 
> -Rob

Well, I can live with whatever is decided on. 8-)  Since I'm not the
one doing the work of maintaining packages, I'll be quiet and let the
experts figure it out.  Certainly in most cases it's satisfactory to
have the plugins, but I guess the main concern is that it's not
possible to just upgrade a plugin separate from the whole bzr install.

Anyway, since I know it's trivial for me to install bzr from source or
build my own packages from source where I want control over the plugins
in use, I can be happy with my bzr no matter what.

Regards,
Colin



More information about the bazaar mailing list