I think it's not a WeeChat bug. WeeChat just displays error from python, so
if you have this error, it's a python problem on your box.
Try to run python (to have interactive python shell), and do that:
I read your comment.
But I still think it's not a WeeChat bug, the error displayed is from python,
not from WeeChat.
I made a test script with "import gtk", like you, and I have no error
displayed in WeeChat.
I realize this bug has been sitting around for three years...but I'm pretty
sure this is a bug in weechat. It seems quite reproducible. First, we start
with python on the command line, just to demonstrate that things are working
Python 2.7.5 (default, Nov 12 2013, 16:18:42)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pynotify
Now, we load the lnotify.py script in weechat, and it works just fine:
/script install lnotify.py
python: loading script "/home/username/.weechat/python/lnotify.py"
python: registered script "lnotify", version 0.1.3 (lnotify - A
libnotify script for weechat)
The bug was not waiting, it was closed. So I reopen it.
I just tried to install lnotify.py, remove it, and reinstall it again, I have
no such error with gdk.
I'm using Debian Sid, Python 2.7.6, WeeChat 0.4.4-dev (same result with
I tried on 2 machines: one with X, the other without X.
In both cases, I never see the error you have, so I'm not able to reproduce
I can reproduce the this problem on my Fedora 21 based system, using
* WeeChat 1.0.1, ncurses client
* PyGTK version 2.24.0
* Python 2.7.8
* "anotify.py" script, version 1.0.1
when reloading "anotify" (as described in comment #6).
@Sebastién: Which version of lnotify have you been using? It seems that
lnotify has changed and does not use pynotify anymore, at least not since
It seems like dynamic objects (_gtk.so) are loaded only once per _process_,
which is why the initialization code is not re-run the second time the import
is triggered (by importing pynotify, which imports gtk, which imports _gtk),
and thus the module directory of the new interpreter state is not populated
with the "gdk" module. Comment #6 was on the right track suspecting the
"weird magic" that is involved in loading "gdk", and that there is at least
_something_ on the WeeChat side (using sub-interpreters within a single
process) that triggers this bug (gtk being unable to find the "virtual" gdk
This bug will also be triggered if two more more different Python scripts are
are importing the "gtk" module -- only the first one will succeed.
However, if anything, it can be considered a bug in Python, or in the
implementation details of PyGTK (not allowing for proper reloading), but it is
definitely not a bug in WeeChat. I am not sure if there is a workaround that
does not involve chancing either Python or PyGTK.