[arch-general] shebang for python scripts
Hi all, I've opened https://bugs.archlinux.org/task/28881 "meld uses wrong shebang" some time ago. The description reads: ,---- | meld uses "#! /usr/bin/env python2" as shebang. It should use "#! | /usr/bin/python2". `---- The bug has been closed as "Not a bug" and "Works fine as-is". I've tried to reopen it, which has been denied, with the following comment: ,---- | Reason for denial: | Avoid using virtualenvs or install pygtk in them. `---- The above is not a "reason for denial" but a workaround, and strictly speaking a bad workaround. A good workaround would be to "put no custom paths in front of the archlinux provided paths in PATH". I really do think the user should be able to install custom python versions in his home directory (be it through virtualenv or by compiling from sources) and put them in front of PATH without breaking random python scripts in /usr/bin. Generally I'm quite impressed by the good decisions and great work being made by the archlinux developers, but in this case I'm deeply disappointed and can't really understand the rationale behind this decision. Can someone explain it to me please? Please also explain why some programs do have a /usr/bin/python2 shebang and some don't! -- Cheers Ralf
On Sat, Apr 14, 2012 at 09:01:30PM +0200, Ralf Schmitt wrote:
Hi all,
I've opened https://bugs.archlinux.org/task/28881 "meld uses wrong shebang" some time ago. The description reads:
,---- | meld uses "#! /usr/bin/env python2" as shebang. It should use "#! | /usr/bin/python2". `----
The bug has been closed as "Not a bug" and "Works fine as-is". I've tried to reopen it, which has been denied, with the following comment:
,---- | Reason for denial: | Avoid using virtualenvs or install pygtk in them. `----
actually I originally switched to arch to have pygtk available for the python version in use. but this is just marginally related to your issue, which is IMO sufficiently invalidated by [1]. #!/usr/bin/env python2 and #!python2 in my experience have exactly the same effect, so all I can do is ask you what differences you found and then we could discuss how to work them around. A good proof of concept / educating experiment in that context would be to try running a python and pygtk fully in your home directory and without the repo versions present; if you have questions, please come back here with more factual questions. I'll gladly help you out. cheers! mar77i [1] http://www.python.org/dev/peps/pep-0397/
On 2012-04-15 07:03, Martti Kühne wrote:
#!/usr/bin/env python2 and #!python2 in my experience have exactly the same effect, so all I can do is ask you what differences you found and then we could
Nobody is talking about "#!python2", but about "#!/usr/bin/python2". The former, "#!python2", is actually equivalent to "#!./python2"; i.e. the one in the current directory. The difference between "#!/usr/bin/python2" and "#!/usr/bin/env python2" becomes obvious when you have multiple `python2`s in your $PATH. -- Mantas M. <grawity@gmail.com>
On Sun, Apr 15, 2012 at 12:36:09PM +0300, Mantas M. wrote:
On 2012-04-15 07:03, Martti Kühne wrote:
#!/usr/bin/env python2 and #!python2 in my experience have exactly the same effect, so all I can do is ask you what differences you found and then we could
[...]
The difference between "#!/usr/bin/python2" and "#!/usr/bin/env python2" becomes obvious when you have multiple `python2`s in your $PATH.
-- Mantas M. <grawity@gmail.com>
question to OP: what is it you have there in your home directory and would renaming the binary work for distinction? ~/bin/python2.6, ~/bin/python-frobtweaks looks like a good measure to me, to just avoid naming collisions if you run into problems. technically, you don't even need to prepend PATH to break your python2 searchpath, since a custom-built binary in /usr/local/bin would already achieve that. cheers! mar77i
Martti Kühne <mysatyre@gmail.com> writes:
question to OP: what is it you have there in your home directory and would renaming the binary work for distinction? ~/bin/python2.6, ~/bin/python-frobtweaks
I'm using virtualenv, so I have a "copy" of the system python in my user's home directory. Judging from the blogs/mailing lists's I read this is best practive if you're developing with python.
looks like a good measure to me, to just avoid naming collisions if you run into problems. technically, you don't even need to prepend PATH to break your python2 searchpath, since a custom-built binary in /usr/local/bin would already achieve that.
you're talking about that as if breaking things was my intention here :) Renaming would work, but I do not see that as an acceptable solution. The problem is the shebang and that should be fixed. I really fail to see why I even have to explain that stuff. Users should be able to install custom interpreters for their favorite scripting languages, and they should be able to also put them first in the search path without breaking system binaries that happen to be implemented in one of those scripting languages. It's easy to fix. Every other distribution I know of does this right. Why do the archlinux developers fail to see the problem here? -- Cheers Ralf
On Sun, Apr 15, 2012 at 09:51:44PM +0200, Ralf Schmitt wrote:
Renaming would work, but I do not see that as an acceptable solution. The problem is the shebang and that should be fixed.
I really fail to see why I even have to explain that stuff. Users should be able to install custom interpreters for their favorite scripting languages, and they should be able to also put them first in the search path without breaking system binaries that happen to be implemented in one of those scripting languages. It's easy to fix. Every other distribution I know of does this right. Why do the archlinux developers fail to see the problem here?
another simple question: why would you think this problem should not be resolved upstream? cheers! mar77i
Martti Kühne <mysatyre@gmail.com> writes:
On Sun, Apr 15, 2012 at 09:51:44PM +0200, Ralf Schmitt wrote:
Renaming would work, but I do not see that as an acceptable solution. The problem is the shebang and that should be fixed.
I really fail to see why I even have to explain that stuff. Users should be able to install custom interpreters for their favorite scripting languages, and they should be able to also put them first in the search path without breaking system binaries that happen to be implemented in one of those scripting languages. It's easy to fix. Every other distribution I know of does this right. Why do the archlinux developers fail to see the problem here?
another simple question: why would you think this problem should not be resolved upstream?
that's what I think. upstream in this case is archlinux. distutils installs executable scripts with the full path to the python interpreter.
On Mon, Apr 16, 2012 at 12:25:39AM +0200, Ralf Schmitt wrote:
that's what I think. upstream in this case is archlinux.
no. [1] is upstream.
distutils installs executable scripts with the full path to the python interpreter.
no again. meld's source package is built with make, see [2]. not with distutils. at least, that's how the meld devs tell you to install it in their INSTALL file. archlinux is indeed modifying the shebang because they/we use python3 as default python. the source package contains the line "#! /usr/bin/env python", which arch has no further reason to modify. so, if we now have sorted everything out correctly, you best ask the meld devs why they do it this way. oh and here's a list of python scripts in my /usr/bin who's devs would also have to update their shebangs. [3] cheers! mar77i [1] http://meldmerge.org/ [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=p... [4] http://ix.io/2jk
Martti Kühne <mysatyre@gmail.com> writes:
On Mon, Apr 16, 2012 at 12:25:39AM +0200, Ralf Schmitt wrote:
that's what I think. upstream in this case is archlinux.
no. [1] is upstream.
ok. I have something like 20 broken shebangs in /usr/bin. I won't contact the authors of those packages but just fix them locally instead if archlinux ships them this way. I still think archlinux should fix that.
distutils installs executable scripts with the full path to the python interpreter.
no again.
sure it does.
meld's source package is built with make, see [2]. not with distutils. at least, that's how the meld devs tell you to install it in their INSTALL file.
archlinux is indeed modifying the shebang because they/we use python3 as default python. the source package contains the line "#! /usr/bin/env python", which arch has no further reason to modify.
so, if we now have sorted everything out correctly, you best ask the meld devs why they do it this way. oh and here's a list of python scripts in my /usr/bin who's devs would also have to update their shebangs. [3]
that's just ridiculous. Just because upstream ships broken packages, archlinux doesn't have to ship them in the same broken way. -- Cheers Ralf
On 16/04/12 16:41, Ralf Schmitt wrote:
Martti Kühne <mysatyre@gmail.com> writes:
On Mon, Apr 16, 2012 at 12:25:39AM +0200, Ralf Schmitt wrote:
that's what I think. upstream in this case is archlinux.
no. [1] is upstream.
ok. I have something like 20 broken shebangs in /usr/bin. I won't contact the authors of those packages but just fix them locally instead if archlinux ships them this way. I still think archlinux should fix that.
distutils installs executable scripts with the full path to the python interpreter.
no again.
sure it does.
meld's source package is built with make, see [2]. not with distutils. at least, that's how the meld devs tell you to install it in their INSTALL file.
archlinux is indeed modifying the shebang because they/we use python3 as default python. the source package contains the line "#! /usr/bin/env python", which arch has no further reason to modify.
so, if we now have sorted everything out correctly, you best ask the meld devs why they do it this way. oh and here's a list of python scripts in my /usr/bin who's devs would also have to update their shebangs. [3]
that's just ridiculous. Just because upstream ships broken packages, archlinux doesn't have to ship them in the same broken way.
I'd consider using "#!/usr/bin/evn python" over "#!/usr/bin/python" a feature and not a bug as it allows me to put a local version of python earlier in my path to test bugfixes etc. So I would actually vote to switch all the #! to using /usr/bin/env... Allan
On Mon, Apr 16, 2012, at 16:59, Allan McRae wrote:
I'd consider using "#!/usr/bin/evn python" over "#!/usr/bin/python" a feature and not a bug as it allows me to put a local version of python earlier in my path to test bugfixes etc. So I would actually vote to switch all the #! to using /usr/bin/env...
yes, please do this for perl, ruby, tcl and last but not least for shell scripts too. It's at least consistent that way.
participants (5)
-
Allan McRae
-
Mantas M.
-
Martti Kühne
-
Ralf Schmitt
-
ralf＠systemexit.de