GNOME Bugzilla – Bug 677979
jhbuilds setting PYTHONPATH does not work with python 3.x
Last modified: 2012-06-14 10:18:01 UTC
jhbuild attempts to set PYTHONPATH by executing the PYTHON env variable and pulling the python version from sys.version_info. Similarly it uses this technique to determine the prefix/<packages-dir>. Both of these silently fail when setting PYTHON to python3 the code in question uses the older style of "print" which is not compatible with python3. This failure is then caught and silently sets these to the currently execution version of python. In general it seems this code should be a little more robust in that if PYTHON is explicitly set and an error occurs we should at least get a warning instead of a silent failure and defaulting to the currently running python.
The affects of this are as follows: $ export PYTHON=/usr/bin/python3 $ env | grep PYTHON PYTHON=/usr/bin/python3 $ jhbuild shell $ env | grep PYTHON PYTHONPATH=/opt/gnome3/lib/python2.7/site-packages:/opt/gnome3/lib64/python2.7/site-packages PYTHON=/usr/bin/python3 Note the python2.7 in PYTHONPATH which is being pulled from the python in which jhbuild is running in.
Created attachment 216238 [details] [review] Fixed setting of PYTHONPATH with PYTHON set to python3 Added parentheses to the code used for deterimining python version and site-packages to support PYTHON set to python3. Also added warning when PYTHON is explicitly set and an error occures when running the code for making these determinations.
Comment on attachment 216238 [details] [review] Fixed setting of PYTHONPATH with PYTHON set to python3 Just a minor thing: you need to call gettext on displayed messages. (also I am quite sure you'll have many issues trying to run python3 as the default python, but you'll help unveil them, that's good).
Created attachment 216354 [details] [review] Updated patch with gettext Hi Frederic, I added what I think to be gettext based on what the rest of the code is doing (wrapping strings with _("")). It may help improve readability to explicitly assign "_" at the top of each file it is used in as there is no telling where it is coming from or what it does (besides guessing it is assigned globally in __buildin__ somewhere), something along the lines of: _ = jhbuild.utils.gettext OR from jhbuild.utils import gettext as _ And yes, it looks like there will be many problems like this for when targeting python3. Thanks!
I pushed it, thanks! It's usual to have _ set in builtins (see <http://docs.python.org/library/gettext.html#gettext.install>) so I don't think a special notice needs to be added.
I didn't realize _ was part of the standard lib gettext, only that it stores the last evaluation in an interactive console which made it initially confusing. The trouble I had was mainly related to trying to find info about a function named _ in docs or code :)