GNOME Bugzilla – Bug 574501
build script looks for site-packages instead of dist-packages folder
Last modified: 2015-02-07 16:52:16 UTC
Please describe the problem: 'jhbuild run g-ir-scanner' fails using python 2.6 on Ubuntu Jaunty. Traceback (most recent call last):
+ Trace 213258
from giscanner.annotationparser import AnnotationParser, InvalidAnnotationError ImportError: No module named giscanner.annotationparser
annotationparser.py (and other files) is in ~/gnome-shell/install/lib/python2.6/dist-packages/giscanner/ but script looks for it in ~/gnome-shell/install/lib/python2.6/site-packages/giscanner/ Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
There's some mention of a rationale at https://wiki.ubuntu.com/Python2.6And3.0 As far as I can tell, the point is to be able to have both: Distributed Python 2.6 look in /usr/local/python-2.6/dist-packages for extra localy installed modules Locally installed (configure && make && make install) Python 2.6 look in /usr/local/python-2.6/site-packages for extra locally installed moduless It sounds a bit crazy to me - a huge divergence from upstream and other operating systems to support something very marginal, so I'm probably missing something. Two possible fixes: 1) In the python code scan the sys.path for strings with dist-packages in them and use that to figure out what the setup is. 2) Config-substitute $pythondir into g-ir-scanner rather than basing off of argv[0]. 2) is probably the more robust approach and avoids the need to comment a bunch of weird looking code.
I'd suggest a different fix - install the python module into e.g. /usr/lib/gobject-introspection/scanner/giscanner, and config-substitute that ($pkglibdir) in the g-ir-scanner script. I've always thought that while python's module system is nice and convenient for development, it does encourage pollution of the global namespace for internal components when installed.
Created attachment 130344 [details] [review] Bug 574501 - Install giscanner Python module to private directory We don't want to pollute the global namespace with our private libraries. Also, this sidesteps all the craziness that is happening with OS vendors changing how Python installs modules.
(In reply to comment #3) > Created an attachment (id=130344) [edit] > Bug 574501 - Install giscanner Python module to private directory > > We don't want to pollute the global namespace with our private > libraries. Also, this sidesteps all the craziness that is happening > with OS vendors changing how Python installs modules. > Okay, looks pretty good except that there's always something which bothers me about editing .in files. Can you move over the bulk of tools/g-ir-scanner to giscanner/scannermain.py or so? So the .in script is basically only setting up the path and importing the main entry point. That way we'll avoid editing .in files most of the time.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]