GNOME Bugzilla – Bug 733704
Jhbuild does not function correctly when multiple versions of python are installed
Last modified: 2014-07-26 06:31:19 UTC
Created attachment 281648 [details] [review] Patch: Use Autoconf probed python JHBuild's scripts/jhbulid uses a #! of /usr/bin/env python which on some systems may be a different version of python. The script should use the version of python that was discovered and used from Autoconf/Automake Attached is a patch that should make it work. On my system (arch) /usr/bin/python -> python 3 and /usr/bin/python2 -> python 2 I didnt know if we should be parsing the last part of $PYTHON to create an env #! like: #!/usr/bin/env @PYTHON@ Excuse my lack of experience with that part. Is it ok to set the #! directly to python when that python path was probed for with configure?
Created attachment 281651 [details] [review] Correct patch for jhbuild / python discovery Previously attached patch for different project This should cause jhbuild to use the system specified (python2) location
Comment on attachment 281651 [details] [review] Correct patch for jhbuild / python discovery Obviously correct and a very serious problem for new GNOME contributors on Arch, so commited with a whitespace fix.
Leaving this bug open since some of the other scripts in scripts/ might be wrong too (have not tested). If anyone wants to do this differently, just please make sure to comply with PEP 394: http://legacy.python.org/dev/peps/pep-0394/ * "python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3." * "in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line."
I reverted the patch (please do not push things as fast), because as you later pointed, the approved way is to set python2 on the shebang line. commit 4fc5e0ef8907b396175820f83fe26f5e4dd724df Author: Frédéric Péters <fpeters@0d.be> Date: Fri Jul 25 13:57:25 2014 +0200 Refer to python2 in shebang lines (PEP 394)
OK, that was too fast, you're right. Using python2 is the correct/approved way, but it won't work in Debian Wheezy or OS X since those systems have only python and not python2. That might be acceptable because both those systems are clearly in the wrong, but this is why AM_PYTHON_PATH might be a better approach.
Wheezy has /usr/bin/python2.
Oh that's wonderful; it did not when it was released, so it must have been added in an update.
If I understand correctly: We use #!/usr/bin/env for situations where the location of the actual binary may vary in a different environment (e.g. /usr/bin/python on Machine1 and /opt/bin/python on Machine2, but both on the PATH). In this case Autoconf/Automake have already probed for the path of Python, therefore we should be able to use the direct PYTHON path from there. If not this leads to situations where ./configure has probed for a PYTHON, used it in the build / test / etc. but that version may not be used when the script is actually run. By using a dynamic PYTHON we are able to allow the person running ./configure to actually select the python interpreter that we want to use. Also, by using $PYTHON could be the first step for Python3 porting (run `PYTHON=/usr/bin/python3 ./configure && make`) The point of Autoconf and Automake is to allow us to make this kind of portability possible I think. A second idea may be to transform $PYTHON (/usr/bin/python2) -> just the binary name (python2) then we can set the shebang #!/usr/bin/env @PYTHON@ where @PYTHON@ = "python" || "python2"
Sorry for the double post, but I've considered a case where this is still a bug... Theoretical System: python3 installed as /usr/bin/python3 -> symlink /usr/bin/python python 2 not installed, no /usr/bin/python2 Upon cloning JHBuild: 1) User ./configure JHBuild, configure succeeds because AM_PATH_PYTHON probes for and finds version > 2.x (3), $PYTHON = /usr/bin/python 2) User runs jhbuild, gets error from sh with cannot find /usr/bin/python2 If I understand the PEP correctly, using #!/usr/bin/env python2 is intended for scripts that are not distributed via Autoconf/Automake to ensure that python2 is available. Using the previous patch is the only way to ensure that we are using the version of PYTHON that came from our portable configure script...
/usr/bin/env python2 should point to a python 2.x program, always; iarchlinux decided to have python → python3 (that created a lot of incompabilities and was done, in my opinion, without enough consideration), then the python community thought about it, and the result is PEP 394.
The PEP seems to apply to scripts deployed to run without Autoconf/Automake Fixing this bug has two options: 1) Use the probed PYTHON as per patch 2) Change configure.ac to instead check that /usr/bin/env python2 works and remove AM_PYTHON_PATH sense it does not end up being useful (it doesn't check for python2 but for any python interpreter) If 2 is selected, there's not much point to using Autoconf at all for this project. Autoconf is intended to enable system portability, if there is a ./configure script who's settings aren't respected it can really confuse users of this package.
jhbuild is a python2 program, you can't set python3 in its shebang line and expect it to work. If you want to make a useful patch, you can look at bug 688070 and port jhbuild, it shouldn't be too difficult. And then it could have the configure check changed to make sure python3 is installed (AM_PATH_PYTHON([3])). Also autotools are required to build the help, but skipped (see --simple-install in autogen.sh) if the system doesn't have a minimal set of gnome tools already installed. The patch ignored that (look for jhbuild.in in Makefile.plain).