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

Bug #316192 reported by Michael Hudson-Doyle on 2009-01-11
8
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Vincent Ladeuil
Launchpad itself
High
Tim Penhey

Bug Description

Lauchpad uses our own branch of bzrlib, which is not quite up to date with bzr.dev currently. I have bzr installed from the nightly ppa. If I try to run our bzr executable, I get a message about a new plugin in the system location:

mwh@grond:trunk$ ./sourcecode/bzr/bzr rocks
'module' object has no attribute 'CredentialStore'
Unable to load plugin 'netrc_credential_store' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
It sure does!

Its definitely unfortunate that a system plugin can cause problems for my separate install of bzrlib.

Even setting BZR_PLUGIN_PATH doesn't help.

Related branches

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>

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Tim Penhey (thumper) wrote :

This causes problems in the launchpad code.

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

Changed in launchpad-bazaar:
assignee: nobody → thumper
importance: Undecided → High
milestone: none → 2.2.1
status: New → In Progress
Tim Penhey (thumper) on 2009-01-19
Changed in launchpad-bazaar:
status: In Progress → Fix Committed
Andrew Bennetts (spiv) 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'

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.

Paul Hummer (rockstar) on 2009-02-04
Changed in launchpad-bazaar:
status: Fix Committed → Fix Released
Vincent Ladeuil (vila) wrote :

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

Changed in bzr:
assignee: nobody → Vincent Ladeuil (vila)
status: Confirmed → In Progress
status: In Progress → Fix Committed
Vincent Ladeuil (vila) on 2009-09-04
Changed in bzr:
milestone: none → 2.1
status: Fix Committed → Fix Released
Vincent Ladeuil (vila) on 2009-09-17
Changed in bzr:
milestone: 2.1.0 → 2.1b1
Gary Poster (gary) wrote :

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.)

Robert Collins (lifeless) wrote :

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.

Vincent Ladeuil (vila) wrote :

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.

Aaron Bentley (abentley) wrote :

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.

Max Bowsher (maxb) wrote :

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.

Changed in launchpad-code:
status: Fix Released → New
Max Bowsher (maxb) wrote :

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

Changed in launchpad-code:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers