Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments


Following the success that Ubuntu has had with automatically suggesting the package that provides the command the user is trying to execute[1], bzr could similarly suggest the plugin needed for a command the user is trying to execute, and provide a trivial way to download and install it.



This feature is consistent with bzr's goal to make the overall user experience the best possible, and would emphasize bzr's marvelous plugin infrastructure.

Further Details

Robert Collins proposes:

  • We have the core of bzr support this concept & it be hookable so that plugins can be provided in different ways

  • the debian/ubuntu package of bzr depend on a plugin 'bzr-debfetchplugins' which will provide plugin fetching via apt and kick in when bzr has been installed via debs
  • Ideally, all plugin management should be done through bzr, so this should also provide a way to remove/uninstall plugins.


Use Cases

  1. James is used to his bzr installation of bzr and runs a non-standard command on a fresh install
  2. Jane read about a specific bzr plugin that she wants installed
  3. Joe would like to update a particular plugin to it's latest version
  4. Tim wants to remove a particular plugin without diving into an obscure directory and deleting a folder
  5. Hillary would like to know what additional plugins are available


What it would provide

  • A hook that checks if the command executing is available as a plugin if all else failed, telling the user how he can install it (ie. bzr fetchplugin plugin-name)
  • Install new plugins from a trusted source
  • Install plugins from a possibly arbitrary URL with a switch like --url
  • Update one or all plugins
  • Remove any installed plugins
  • List all plugins available
  • Be pluggable to add a per-platform plugin that handles possible external dependencies


  • All plugins would be installed by doing a lightweight checkout into the users plugin folder, avoiding having to use a new transport method
  • Plugins can then be updated using a simple "bzr update" internally
  • Would allow for the plugins to live in different locations rather then a central one (although it's probably best if we do have a central repository, that would also mean delays in keeping the plugins up to date)
  • Have an XML file hosted on the server which contains the information of all available plugins with the necessary information (commands it provides, description, etc) - Which format to use is under discussion --MartinAlbisetti

UI Changes

Suggested UI by Mark Shuttleworth:

If you shipped a plugin which intercepts a command-not-found event, and checks an internal dictionary of commands and plugins, then you could get this sort of experience:

  peregrine%  bzr shelve

  'shelve' is not a standard bzr command. However, 2 certified plugins provide this command:


  To install a certified plugin, type:

     bzr --fetch-plugin pluginname


This way, bzr can avoid bloat, and people have an incentive to get their plugins approved for a particular release.

Code Changes

Schema Changes

Data Migration


Initially discussed in:

Unresolved Issues

Questions and Answers

  • I'd rather see "bzr fetch-plugin" than "bzr --fetch-plugin" as it is more consistent with the way bzr is usually invoked. -- JelmerVernooij

  • As I raised in the thread, I don't think bzr should ship with a database; it should ship with the ability to access a database and packagers should customise that appropriately (this avoids bloat and allows updates post-release cleanly). Also bzr should not have its own installation method, rather that should be keyed to the plugin that offers the database; this allows clean integration with Ubuntu and correct external dependency management. -- RobertCollins