gedit 'External Tools' plugin hashlib weirdness

[Joel Hedlund]

I'm having a weird problem with the 'External Tools' plugin for gedit,
that seems to get weirder the more I dig into it. When I start gedit
by clicking a launcher (from the Ubuntu menu, panel or desktop)
everything is dandy and the 'External Tools' plugin works as expected.
When gedit is launched from the terminal, the 'External Tools' plugin
is greyed out in the plugin list and I get this traceback on stderr:

$ gedit
Traceback (most recent call last):
File "/usr/lib/gedit-2/plugins/externaltools/__init__.py", line 24,
in <module>
from manager import Manager
File "/usr/lib/gedit-2/plugins/externaltools/manager.py", line 27,
in <module>
import hashlib
File "/usr/lib/python2.6/hashlib.py", line 136, in <module>
md5 = __get_builtin_constructor('md5')
File "/usr/lib/python2.6/hashlib.py", line 63, in
__get_builtin_constructor
import _md5
ImportError: No module named _md5

** (gedit:8714): WARNING **: Error loading plugin 'External Tools'

The same thing happens if I try to activate the plugin from a gedit
launched from the terminal (if it's already been deactivated from a
gedit launched from the menu).

My analysis is that gedit tries to import the externaltools package,
which imports hashlib, which tries to import _hashlib but fails and
falls back to _md5 which also fails, which apparently /should not
happen/, or so google tells me. One of _hashlib and _md5 should always
exist.

However, importing _hashlib in a python interpreter works just fine,
i.e:

$ python -c 'import _hashlib'

returns nothing. What also puzzles me is that I don't seem to have
_hashlib* anywhere on my system (am I supposed to?) and getting the
__file__ attribute off the module doesn't work, and help(_hashlib)
says FILE is (built-in).
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__file__'

Google drops vague hints that there may be a a virtualenv that one
might have to rebuild, but in that case I have no idea where to
begin.

I've tried reinstalling the ubuntu packages gedit, gedit-common and
gedit-plugins, but to no avail. And the machine runs a fully updated
ubuntu karmic koala (10.4) that has survived numerous dist-upgrades,
if that's of any use to anybody.

I'd appreciate any input on this, even if it's just new bushes to
whack for scaring the problem out into the light.

Cheers!
/Joel

 

[Joel Hedlund]

bah, I meant to say I'm running "a fully updated ubuntu lucid lynx
(10.4)".

 

[Peter Otten]

I'm having a weird problem with the 'External Tools' plugin for gedit,
that seems to get weirder the more I dig into it. When I start gedit
by clicking a launcher (from the Ubuntu menu, panel or desktop)
everything is dandy and the 'External Tools' plugin works as expected.
When gedit is launched from the terminal, the 'External Tools' plugin
is greyed out in the plugin list and I get this traceback on stderr:

$ gedit
Traceback (most recent call last):
File "/usr/lib/gedit-2/plugins/externaltools/__init__.py", line 24,
in <module>
from manager import Manager
File "/usr/lib/gedit-2/plugins/externaltools/manager.py", line 27,
in <module>
import hashlib
File "/usr/lib/python2.6/hashlib.py", line 136, in <module>
md5 = __get_builtin_constructor('md5')
File "/usr/lib/python2.6/hashlib.py", line 63, in
__get_builtin_constructor
import _md5
ImportError: No module named _md5

** (gedit:8714): WARNING **: Error loading plugin 'External Tools'

The same thing happens if I try to activate the plugin from a gedit
launched from the terminal (if it's already been deactivated from a
gedit launched from the menu).

My analysis is that gedit tries to import the externaltools package,
which imports hashlib, which tries to import _hashlib but fails and
falls back to _md5 which also fails, which apparently /should not
happen/, or so google tells me. One of _hashlib and _md5 should always
exist.

However, importing _hashlib in a python interpreter works just fine,
i.e:

$ python -c 'import _hashlib'

returns nothing. What also puzzles me is that I don't seem to have
_hashlib* anywhere on my system (am I supposed to?) and getting the
__file__ attribute off the module doesn't work, and help(_hashlib)
says FILE is (built-in).

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__file__'

Google drops vague hints that there may be a a virtualenv that one
might have to rebuild, but in that case I have no idea where to
begin.

I've tried reinstalling the ubuntu packages gedit, gedit-common and
gedit-plugins, but to no avail. And the machine runs a fully updated
ubuntu karmic koala (10.4) that has survived numerous dist-upgrades,
if that's of any use to anybody.

I'd appreciate any input on this, even if it's just new bushes to
whack for scaring the problem out into the light.

You could add

import sys
print sys.executable

at the top of

/usr/lib/gedit-2/plugins/externaltools/__init__.py

Maybe there's some confusion about what python interpreter should be used.

Peter

 

[Joel Hedlund]

How do I catch output to stdout/stderr when launching from a launcher?

I added this to /usr/lib/gedit-2/plugins/externaltools/__init__.py:

import sys
f = open('/tmp/eraseme.txt', 'w')
print >> f, "The executable is %r." % sys.executable
f.close()

In both cases (launcher/termial) the contents of eraseme.txt are:
The executable is '/usr/bin/python'.

 

[Joel Hedlund]

FOUND IT!

I added the line

print >> f, '\n'.join(sorted(sys.path))

and diff:ed the files produced from terminal/launcher.

When using the launcher, changes to PYTHONPATH done in ~/.bashrc are
not picked up, and I apparently had an old reference to /usr/lib/
python2.4 sitting in there. Removed it, reloaded .bashrc, plugin now
works.

The question still remains why gnome disregards ~/.bashrc, but that's
a whole other topic. Thanks a bunch, you guys are ever so helpful.

 

[Joel Hedlund]

I guess the moral of the story is don't always dist-upgrade.

Reformat once in a while to remove old forgotten garbage. Clear the
blood clots from your systems, so to say.

 

[Peter Otten]

FOUND IT!
Heureka!

I added the line

print >> f, '\n'.join(sorted(sys.path))

and diff:ed the files produced from terminal/launcher.

When using the launcher, changes to PYTHONPATH done in ~/.bashrc are
not picked up, and I apparently had an old reference to /usr/lib/
python2.4 sitting in there. Removed it, reloaded .bashrc, plugin now
works.

I'm surprised that /usr/lib/python2.4 doesn't appear in the traceback.

The question still remains why gnome disregards ~/.bashrc, but that's
a whole other topic. Thanks a bunch, you guys are ever so helpful.

I think the breakage you've experienced could be the answer.

Peter

 

[Joel Hedlund]

I'm surprised that /usr/lib/python2.4 doesn't appear in the traceback.

That certainly would have been useful, wouldn't it?

 

[Joel Hedlund]

I apparently replied to soon.

Removing /usr/lib/python2.4 from PYTHONPATH did not solve the problem.
I think I may have had a launcher-started gedit running somewhere in
the background while testing. Any subsequent terminal-launches would
then just create new windows for the existing (non-bugged) process,
rather than starting a new process and tripping the bug (and by bug I
mean configuration error on my part, most likely).

However, I went further along the sys.path diff and found a path to a
second python2.6 installation. Apparently, this one shipped with a
standalone middleware client for distributed computing, and was
insinuated into my PYTHONPATH via a call to its startup script in
my .bashrc. Removing the call to the startup script solved the problem
again (!)

I still can't explain the traceback though.

But fwiw, this solution made the problem stay solved past a reboot, so
I have high hopes this time.

/Joel