GNOME Bugzilla – Bug 658237
Fix Python shebang lines
Last modified: 2017-10-11 09:44:12 UTC
As previously discussed in bug #650763, the patch I'll attach changes Python shebang lines to use #!/usr/bin/env python for glib/gtester-report and glib/update-pcre/make_utt.py scripts (and also drops the space between the #! and the script interpreter name for consistency).
Created attachment 195675 [details] [review] Fix Python shebang lines
You know my intentions. I'm all for preserving the build time shebang. Instead of fixing all modules that don't run in Makefile $(PYTHON) gdbus-codegen(we don't know them, it can be a lot), it can be fixed in only one location and it will work on all systems. http://git.gnome.org/browse/gnome-online-accounts/tree/src/goa/Makefile.am#n25
(In reply to comment #2) > it can be fixed in only one > location and it will work on all systems. I'm sorry, you seem to have misunderstood: hard-coding the location of the Python interpreter used at build time as the value of the script interpreter in the shebang line to be used at runtime does *not* always work on all systems. That's the whole point of using /usr/bin/env python and the PYTHON environment variable...
using a python shebang is wrong in all occasions because nobody ensures you that is always python 2, even in the same family a python script doesn't for all 2.x. You are just using python and hopping that is python 2 version that works. You can preserve python shebang if you do checks in your script and made it work for both python2 and python3 out of the box or change to /usr/bin/env python2
The whole point of a shebang is that ./scriptname.py should work out of the box. If you need to set PYTHON=python2 ./scriptname.py, then you could just use python2 ./scriptname.py instead. On archlinux, /usr/bin/python is Python 3.x. /usr/bin/python2 is Python 2.7. Without setting PYTHON, the "env python" shebang will try to run python2 scripts with python3. If you don't want to fix these shebangs because Makefiles should prepend invocations with $PYTHON anyways, then I vote for removing them completely. As alternative, I could file bugs for every script that doesn't work with Python3, but I don't think we should go that road.
Thanks Dieter. I'd like to see this go back to working in 99% of cases, i.e. how it has always worked, with /bin/env python, before arch made their own precedent.
(In reply to comment #6) > Thanks Dieter. > > I'd like to see this go back to working in 99% of cases, i.e. how it has always > worked, with /bin/env python, before arch made their own precedent. Why do everyone blame Arch for this? Before Arch made the switch there wasn't a python3 released as stable! Your conclusion is moot. I can blame other distros that didn't implement python2 binary for their python 2.x version. Just to be clear, python2 is dead, long live python
The patch looks good to me. Why not getting it in?
One can argue that the changes are not appropriate. PEP-394 was approved and is active. We should change our shebangs to python2 ASAP or at least use the detected python binary in scripts at make install. http://www.python.org/dev/peps/pep-0394/
citing some pep only makes sense if the majority of systems follow it. how is this looking for fedora ubuntu opensuse arch mandriva ?
As far as PEP 394 goes, there are a couple of problems: - win32 is excluded from this PEP and we're trying hard for GLib to be buildable and usable even there - it only standardizes how binaries have to be named: * /usr/bin/python2 is Python 2.x * /usr/bin/python3 is Python 3.x * /usr/bin/python should be Python 2.x, but may be Python 3.x on some bleeding edge distributions - it proposes to hardcode such paths for shebangs. And so, PEP 394 is irrelevant to this issue. Because the problem we are having is that hardcoding the path to the python binary in the shebang line is not portable. Further, we can even fully expect the path to the python binary to be different on multiple computers running the same operating system (and this is especially true for win32). Thus, hardcoding leads to trouble sooner rather than later. That's why we are all using "/usr/bin/env varname" for script shebang lines in the first place: so we can set an environment variable to control the script interpreter that will be used (instead of having to go and edit the source script file). Using the PYTHON envvar is exactly what patch #195675 proposes to do and what was already done in bug #650763. However, using PYTHON as the envvar name might not be a complete solution as it could potentially point to Python 2.x or Python 3.x (analogous to the standardized binary names). We could take it a step further and use PYTHON2 and PYTHON3 envvars, each pointing to their respective interpreter version and then use "/usr/bin/env python2" in scripts that are known to be Python 3 incompatible. And "/usr/bin/env python3" in scripts that are known to support Python 3 only. Most distro's come with an easy mechanism for such env vars to be installed by a package, so PYTHON2 and PYTHON3 can be handled automatically by package managers, leaving PYTHON for the user to fill in with his/her favorite flavor without breaking some of GLib's development tools... Hope this clears things up a bit, mvg, Dieter [1] "platform independent" seemed like the wrong choice of words as GLib itself provides the platform we all use to build our stuff on...
(In reply to comment #7) > > I'd like to see this go back to working in 99% of cases, i.e. how it has always > > worked, with /bin/env python, before arch made their own precedent. I concur. > Why do everyone blame Arch for this? Before Arch made the switch there wasn't a > python3 released as stable! Your conclusion is moot. Because doing so immediately breaks every and any Python script that is out there which does not accidentally happen to work with Python 3 already. This does not just affect glib or GNOME, but also all scripts that other packages ship, as well as all scripts which administrators wrote (note that Python is an excellent language for system integration/administration and thus very popular). python3 is not "just another stable release after 2.7", it's a different language. > I can blame other distros that didn't implement python2 binary for their python > 2.x version. This is not true (e. g. Debian and Ubuntu have /usr/bin/python2 -> python2.7), and also unrelated: The existence of "python2" does not change the fact that scripts which were written for Python 2 with "#!/usr/bin/python" will just break if that suddenly points to Python 3. Besides, "python2" and "python3" must always exist. If they don't, that is a clear packaging bug. (Whereas the behaviour of "python" was unfortunately not clearly defined in that PEP, which leads to this mess.) > Just to be clear, python2 is dead, long live python Fully agreed. But we need to provide a transition path. :-) But anyway, the damage is done so we need some way to cope with it. I think Dieter's patch goes into the right direction (although I don't understand the second and third hunk). But similarly to the discussion about pygobject [1] it would probably be better to use a configure switch instead of, or in addition to, checking $PYTHON so that this will also work in jhbuild. With that, all distros can configure with e. g. --with-python=python2.6 if they want to build for an older Python, and glib would default to "python2" as long as it only works with py2, and could then later switch the internal default to "python3". Due to that fatal "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions" in PEP-394 it seems we just have to stop defaulting to just "python" in either case. [1] https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00005.html
in this period we (as in arch) changed our python policy and now all apps have been compiled with python2 and python3 shebang instead of python. i do agree that python shebag should be fade out from gnome modules.
It works perfectly fine to set the PYTHON environment variable on windows/mingw, I just tested. If anything should be done it should be improving configure.ac to set PYTHON to a reasonable value (something which failed when I tested)
The shebang lines have all been changed recently, and this has been most recently discussed in bug #788527. Since this bug has seen no activity for 5 years, I’m going to close it. If someone has concerns about the state of the Python shebang lines in GLib master, please look at bug #788527 or open a new bug report.