Bug 94714 – pygtk.require sets wrong import directory for gtk python module

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Karol Szumski 2005-06-01 01:55:24 UTC]

Any python program using pygtk.require to determine gtk python bindings location
will fail to load gtk module if it is located in a diretory containing a
non-empty gtk-2.0 directory

Reproducible: Always
Steps to Reproduce:
1.create a non-empty gtk-2.0 directory in the same directory the programs binary is
2.run the program (e.g. porthole)
3.

Actual Results:  
import error appears:

"ImportError: No module named gtk"


Expected Results:  
load correctly and run

checked on pygtk-2.6.1
possibly all versions may be affected

some programs create symlinks to some directories located in /usr/lib in
/usr/bin which triggers this error (i found a symlink to /usr/lib/gtk-2.0 that
was causing all the trouble - some ebuild put it there)

[Comment 1 Dead Schorsch 2005-06-13 12:10:44 UTC]

Is there a work-around? I remove the symlink /usr/bin/gtk-2.0 but now success

[Comment 2 Fernando Serboncini (RETIRED) 2005-06-13 22:27:58 UTC]

I've already checked this out. The problem is with pygtk.py
_get_available_versions() function that search inside sys.path for subdirs that
are named gtk-*. He always thinks that the first match is the right one and
remove all other ones, even if they were previously on sys.path. Totally brainless.
My suggestion is to completely replace this function, hardcoding
/usr/lib/python*/site-packages/gtk-* on it. Or simple comment the "remove any
pygtk dirst first" from it.

[Comment 3 Fernando Serboncini (RETIRED) 2005-07-02 09:20:11 UTC]

As I said before, I think the correct answer to this is something in the line of
(on src_unpack):
sed -i -e "s:sys.path.remove(dir):pass:" ${S}/pygtk.py

If noone comes with a better idea, I'll just add this on pygtk ebuilds.

[Comment 4 Heinrich Wendel (RETIRED) 2005-07-10 08:08:28 UTC]

*** Bug 97858 has been marked as a duplicate of this bug. ***

[Comment 5 Karol Szumski 2005-07-11 09:16:44 UTC]

I don't think there is any other easy-to-do solution (the not-so-easy one would
be writing a script that would verify that the directory really contains the
python modules, and reporting their correct version, etc. I don't know anything
about python so i'm not even sure this is possible).

But as it isn't a _true_ solution (i mean, we just basically assume that there
is only one set of those bindings installed, and they are already in the
sys.path ... which is quite probable, unless someone installed those through
other means than portage ...) so i'll leave it as WORKSFORME ...

[Comment 6 Jakub Moc (RETIRED) 2005-08-06 01:01:18 UTC]

*** Bug 101499 has been marked as a duplicate of this bug. ***