bzrlib.plugin.load_plugins() loads system plugins even for non-system bzrlib

I think there are two issues:
BZR_PLUGIN_PATH should override completely (perhaps with some magic
element to say 'the default path here').

And we shouldn't use the python path for an uninstalled bzr. We should
use it if bzr is installed, just not when running from a source dir.

-Rob

  status confirmed
  importance medium

--
Martin <http://launchpad.net/~mbp>

https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/72227 may be related

This causes problems in the launchpad code.

We are fixing it by explicitly passing in the plug-in directory to the load_plugins() call.

This appears to be affecting production code hosting:

$ ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
'module' object has no attribute 'CredentialStore'
Unable to load plugin 'netrc_credential_store' from '/usr/lib/python2.4/site-packages/bzrlib/plugins'

On Tue, 27 Jan 2009 11:47:06 Andrew Bennetts wrote:
> This appears to be affecting production code hosting:
>
> $ ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
> 'module' object has no attribute 'CredentialStore'
> Unable to load plugin 'netrc_credential_store' from
> '/usr/lib/python2.4/site-packages/bzrlib/plugins'

This should be fixed on staging, so will be fixed for the upcoming rollout.

See bug #412930 which fixes the issue by allowing:
  BZR_PLUGIN_PATH='-site'
Which ensures that bzr loads only its core plugins.

When Launchpad upgrades to the version of bzr that has this fix, please look for lib/lp/codehosting/tests/test_lpserve.py and revert the ``assertFinishedCleanly`` to its formerly clean self. (If you see this before lp:~gary/launchpad/buildout-py merges, then you won't know what I'm talking about. There will be an XXX there referencing this bug once in merges.)

LP will need to either set an environment variable or otherwise call into bzrlib to get this behaviour; so it won't be as simple as reverting something.

If I'm not mistaken, LP *calls* bzrlib so it can either:
- continue to call bzrlib (setting the plugin path explicitly),
- stop calling bzrlib *AND* set BZR_PLUGIN_PATH to the appropriate value

I recommend the later, but the former should be perfectly safe.
I think Aaron (I'll subscribe him to this bug) implemented the LP part and understand the BZR_PLUGIN_PATH behavior,
so I would take his word as final.

In the test suite, lp calls "bzr lpserve" to serve branches, so that's why the environment variable is relevant. As an alternative, we could probably serve branches directly using bzrlib, but I'm not sure what's best.

This seems to have regressed, given that I just had to uninstall my system bzr-gtk and bzr-rebase to avoid test failures in
lp.codehosting.tests.test_lpserve.TestLaunchpadServe - this is using db-devel r8806 i.e. 3.1.12 rollout, which uses bzr 2.1b3.

Per discussion on #launchpad-dev, we will leave this bug closed and track the regression as bug 497731.