[MERGE] Give full control over plugins to bzrlib clients

[Robert Collins]

On Thu, 2008-11-13 at 15:33 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> This patch gives bzrlib clients the control they need over which plugins
> are loaded.

I'm replying to this conceptual level stuff now; once we have consensus
here I will happily review the code.

> The plugin path is no longer set when bzrlib is imported.  Clients that
> want a plugin path set should call set_plugins_path.

I'd like to understand more about why this is needed/good. It seems
wrong to me that everyone enabling bzrlib plugins would have to do
bzrlib.plugin.set_plugins_path()
bzrlib.plugin.load_plugins()

The first line is really dead wood, isn't it ? Or have I misunderstood
how it will look?

> load_plugins now allows clients to specify exactly which path should be
> used.  This allows clients to avoid importing plugins from system plugin
> location.

I like this part as long as its optional to specify the path. Nearly all
the bzrlib clients I know of (loggerhead, pqm, config-manager, olive)
want the same plugin location as bzr itself. The only one I know of that
doesn't is launchpad.

> disable_plugins now prevents plugins from being directly imported, even
> if they are bundled with Bazaar.  It is implemented in terms of
> load_plugins.

I like this, I think its an improvement on our current behaviour.

> Finally, I've removed Vincent's colordiff change, since it is no longer
> needed to make "bzr selftest --no-plugins" work correctly.

I think vincent's change was an improvement, because it allows different
plugins to set the colour code. Even without a registry this is useful
because people can write decorators.

> There are no tests, because plugin machinery is hard to test.

There are plenty of existing tests; I'm happy to give pointers on how to
extend them; I acknowledge some parts (particularly the 'what happens on
default bzrlib load') may be tricky to test and am not going to ask you
to increase the test coverage; however decreasing the test coverage in
this area is not a good thing, because it will let the plugin machinery
become buggy, and harder to test, over time.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081114/cf8a0d1b/attachment-0001.pgp