piglit: 40b5d5288991fec2cc76ea4af7050555be467126 (master) $ ./piglit-run.py --help env: python2: No such file or directory commit 40b5d5288991fec2cc76ea4af7050555be467126 Author: Dylan Baker <baker.dylan.c@gmail.com> Date: Mon Jun 16 14:54:18 2014 -0700 python: change she-bang to python2 This replaces #!/usr/bin/env python with #!/usr/bin/env python2, which fixes the build on archlinux. This has been proposed before, but at that time debian didn't provide a python2 executable, so it would break debian. Debian sid as of today provides python2. v2: - fix piglit as well Signed-off-by: Dylan Baker <baker.dylan.c@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Well ain't that nice. So what distro is this? You can run it with 'python' explicitly, e.g. 'python piglit-run.py arg1 arg2 ...'
(In reply to comment #1) > Well ain't that nice. So what distro is this? > $ sw_vers ProductName: Mac OS X ProductVersion: 10.9.3 BuildVersion: 13D65
(In reply to comment #2) > (In reply to comment #1) > > Well ain't that nice. So what distro is this? > > > > $ sw_vers > ProductName: Mac OS X > ProductVersion: 10.9.3 > BuildVersion: 13D65 Ah of course. Well, IMHO it's *idiotic* for a distro to make 'python' resolve to anything other than python2 -- too many things assume it to just flip it to mean python3. Unfortunately I am not the king of python or all (any, really) distros... We can just declare that ArchLinux is broken for doing this, but even e.g. gentoo has a way of configuring what 'python' is by default. Not sure what the right way to deal with this is.
While I agree that pytho should be python2 (as does most of the python developers, though I can't for the life of me find the link where the BDFL said it's a strong recomendation), we can't change that for Arch. It's been argued into the ground with them that they're being stupid and we can't win, and I'm not going to try. How many users do we have on OSX right now? I'm not aware of any, and assuming that is true, IMO it's not a regression. Fixing this for arch users (which we have several) is definately a plus.
python2 also does not exist on NetBSD, OpenBSD, and Solaris. piglit is a cross-platform OpenGL test suite. We should not break multiple operating systems in favor of one distribution of one operating system.
(In reply to comment #5) > python2 also does not exist on NetBSD, OpenBSD, and Solaris. > > piglit is a cross-platform OpenGL test suite. We should not break multiple > operating systems in favor of one distribution of one operating system. I know there is one solaris user, so I won't discount him. But how many *BSD users do we have? and how many OSX users? I'm making the pragmatic argument that making things work out of the box for the largest number of people is best for the project. As Ilia points out one can still run these programs via 'python piglit*'. I'm willing to bet that there are more developers/users of piglit running arch than running OSX + *BSD + solaris. My second argument is that it is easier to add python2 to one's path if they don't have one than for a developer using arch to make python point at python2, since this will break everything python based installed by their package manager, including tools they need to configure their systems.
I dunno, I'm just as happy sticking it to archlinux users for picking a distro that decided they're going to do things the stupid way. If enough projects do it, fewer people will use it and/or perhaps they'll fix it.
I'm willing to revert it. I just don't want to revert it on a kneejerk reaction that we are inconveniencing theoretical users. I will point out that this is just another reason to use python3...
I have sent a patch to the list to revert the patch in question. I would like this to have some wider community input before just pushing. If no one complains that this patch has broken their system in the next couple of days I'd like to leave it on the list for a couple of days for comments. If no one bothers to comment by then, and no one has complained we'll revert it. Does that sound reasonable to everyone?
I argue that we keep `#!/usr/bin/env python2`. In a nutshell, my argument is... `#!/usr/bin/env python2` can be easily made to work for all people. But `#!/usr/bin/env python` cannot be made to work for some people. Here's the reasons... 1. On systems that do not provide a python2 executable, there are two quick and easy fixes available. So, I believe there is no strong reason for anyone to complain about Dylan's patch. Fix #1: $ sudo ln -s /usr/bin/python /usr/bin/python2 Fix #2: $ ln -s /usr/bin/python ~/bin/python2 $ export "PATH=$HOME/bin:$PATH" 2. On Archlinux, you cannot fix scripts in which `#!/usr/bin/env python` expect Python 2.0 by simply making a symlink `python -> python2`. The symlink breaks other stuff on Arch, because Arch already symlinks `/usr/bin/python3 -> /usr/bin/python` and many Arch packages rely on that.
(In reply to comment #10) This paragraph in my comment #10 had an error. Here's the paragraph corrected... > 2. On Archlinux, you cannot fix scripts in which `#!/usr/bin/env python` > expects Python 2.0 by simply making a symlink `python -> python2`. The > symlink breaks other stuff on Arch, because Arch already symlinks > `/usr/bin/python -> /usr/bin/python3` and many Arch packages rely on that.
hacky multiline shebang could be used to fix this for all based on http://rosettacode.org/wiki/Multiline_shebang#Python #!/bin/sh "exec" "$(command -v python2 || command -v python)" "$0" "$@"
Apparently resolved in favor of "#!/usr/bin/env python" by: commit 5fece51da7eef4893ae6c2fd6d642c41a4ed4e59 Author: Dylan Baker <baker.dylan.c@gmail.com> Date: Wed Mar 30 11:18:39 2016 -0700 framework: update the rest of the piglit-* commands to be py3 Convert the rest of the commands using six to make them both python 2 and python 3 safe. This also changes the default chbang to python instead of python2, which should only be a change on Arch linux. Signed-off-by: Dylan Baker <dylanx.c.baker@intel.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.