Python plugins, third round

[Martin Pool]

On 14 Jun 2005, Lalo Martins <lalo at exoweb.net> wrote:

> Well, after years of working with Zope, I developed a deep appreciation
> for "explicit is better than implicit" and a strong distaste for
> software that depends on naming conventions to work right.  

> So I was thinking.  Why do we need to automagically search plugins at
> all?  I'd prefer the user to be personally aware of any and all plugins
> he is loaded.

I agree with those.

To step back a bit: plugins could be useful for several things:

- code that wants to eventually be in bzr itself, but isn't merged yet

- user-specific or site-specific code, perhaps implementing some kind of
  policy or shortcut

- widely used packages that for whatever reason are not going to be
  distributed with bzr itself

This is somewhat similar to, amongst other things, libraries for
Python or emacs.  That comparison points out that people might want to
install plugins per-user or systemwide, and that some things can be
done to make it easier for distributors to include plugins.

> Also, if plugin loading is made explicit, it may allow on-demand
> loading, because then we know what kind of functionality is implemented
> by each plugin.
> 
> So what I'm proposing is an explicit plugin system, controlled by
> configuration.  Better to explain by example; this would be an excerpt
> of a configuration file (as we haven't picked a configuration file
> format, I'm making one up as I go, which I think people will understand)
> 
> -----
> 
> plugin /home/lalo/src/baz2bzr/plugin/baz2bzr:
>   BranchStorage ArchArchiveBranchStorage
>   Command cmd_convert_from_arch
> plugin /home/lalo/src/bzrexport_misc:
>   Exporter win_installer win_installer.make_win_installer
>   Exporter deb deb.build_binary_package
> plugin /home/lalo/src/bzrchangelog:
>   Command cmd_make_changelog
> 
> -----

Why invent a new language when we have Python?

I'd like bzr to just read a per-user and a system-wide startup file;
this can in turn import other modules.  It could register commands,
and in the future possibly set up other hooks.  This should be on by
default, but --no-init-file could disable it.

This is rather different to how shell plugins work but then it's a
different problem.

As a performance optimization we might have

  register_command_autoload('foo', 'bzrlib.plugin.foo', 'cmd_foo')

which will do the import when the command is first needed, perhaps by
making some kind of proxy object.

-- 
Martin