Proposal for plugin management UI

Michael Ellerman michael at ellerman.id.au
Tue Jun 6 02:43:36 BST 2006


On 6/6/06, John Whitley <whitley at acm.org> wrote:
> Wouter Bolsterlee wrote:
> > Long story short: please think from a user perspective. Users don't
> > want to
> > install LOTS of plugins if they can get them all at once.
>
> While I agree with the notion of thinking from a user perspective,
> bundling plugins isn't necessarily the best way to achieve ease of
> plugin management.
>
> I'd suggest that one way to manage this is to use bzr itself to
> implement a plugin management system via lightweight checkouts.
> Here's a first pass at a plugin management UI and implementation sketch:
>
> # Searches known Bzr plugin sites for plugin 'Foo', and grabs a
> lightweight checkout
> bzr plugin --install Foo
>
> # Install a plugin from the specified plugin site
> bzr plugin --install JoesAmazingPlugin --site http://joes-plugins.org/
> bzr/
>
> # Add a new plugin site
> bzr plugin --add-site http://bestbzrplugins.net/plugins/
>
> # Edit the list of known sites
> bzr plugin --edit-sites
>
> # Updates the lightweight checkouts for all installed plugins
> bzr plugin --update
>
> # Updates the specified plugin
> bzr plugin --update JoesAmazingPlugin
>
> # List/query operations
> bzr plugin --list-installed [search term]
> bzr plugin --list-remote [search term]
>
> # Remove plugins
> bzr plugin --remove Foo
>
> Other considerations and proposed solutions include:
> * Management of system-wide vs. user-local plugins
>    Default to user-local for non-root users on *nix systems, system-
> wide for root users,
>    have explicit option to specify local plugin directory
>
> * Dependency management
>    If plugins depend on other plugins, then some sort of dependency
> specification and management
>    is essential.
>
> Thoughts?  If some form of this proposal is meets with approval, I'll
> write the plugin management plugin (doh!) to test out these ideas,
> with an eye towards its eventual inclusion in bzr core.
>
> If it turns out that there are popular sets of plugins, it would be
> fairly easy to add support  such as:
>
> bzr plugin --install-bundle BzrTools
>
> where BzrTools is simply a file in a standard location on a plugin
> site listing other plugins to install.
>
> Or an alternative, that just installs all plugins from the given URL:
>
> bzr plugin --install-site http://thebestofbzr.com/plugins/
>
> -- John

Mmmm, I think that's a little over engineered for what we really need.

As I see it there's two classes of users:
 - The Eriks, who want to run bleeding edge plugins, and manage them by hand.
 - The Wouters, who just want what works, and want it now!

The first class I think is served quite well by the current system,
they just cd into ~/.bazaar/plugins and branch from the plugin's URL.
Not too hard.

The second class is served quite well by bzrtools, they just apt-get
install it, or if they're adventurous they branch the development
version into ~/.bazzar/plugins.

The _only_ problem with the current system IMHO is that you can't
easily use bzrtools in conjunction with a development version of one
of the bzrtools plugins.

There's actually no problem having two version of the plugins
installed, it's just when they try to register the same command name
you get a clash and an error.

I think the best solution to that is to implement Aaron's idea:
 - all commands are actually registered with the full path of the
plugin module, in addition to the "shortname". eg: "bzrtools-shelve",
"shelf-shelve" etc. Normally these are hidden from the user.
- if two plugins try to register the same command, neither of them
wins, but it's not an error, and the user must choose one or the other
by defining an alias to the long-name of one of the commands. There
should be lots of help text to make this easy.

cheers




More information about the bazaar mailing list