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)
Is there a work-around? I remove the symlink /usr/bin/gtk-2.0 but now success
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.
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.
*** Bug 97858 has been marked as a duplicate of this bug. ***
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 ...
*** Bug 101499 has been marked as a duplicate of this bug. ***
