<span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">> LGTM. Please specify what /usr/bin/python is supposed to be also<br>
> (rather: the "python" utility). I'd like it ruled out that<br>> installations *only* provide python2 and python3 - "python" could<br>> be either one, but should be present "normally" (i.e. SHOULD<br>
> in the RFC 2119 sense).<br>> <br>> Nitpickingly, I'd add that scripts can, of course, also specify<br>> python2.7 (or some such). Actually, scripts can do whatever they<br>> want - it's more about what they then can expect to happen.</span><br>
Good points--I've taken them into account in the revised PEP, which I will send to this list shortly.<div><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">> OTOH, my<br>
> cynical side doubts that script authors read PEPs so it'll take either<br>> upstream python shipping without /usr/bin/python or consensus among the<br>> distros to ship without /usr/bin/python to reach the point where script<br>
> authors realize that they need to use /usr/bin/python{2,3} instead of<br>> /usr/bin/python.</span></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">I don't see this as an issue: all it will take is for one user with a different "python" to contact a developer once, referring the developer to the PEP, and then every program that that developer ever writes in the future will be fixed (and, if the developer's worth anything, every program he's already written, as well). Word of mouth tends to pass these things around quickly.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><span style="font-size:13px">> Actually, I think this is *not* a good idea for distro provided scripts. For<br>
> any Python scripts released by the distro, you know exactly which Python it<br>> should run on, so it's better to hard code it. That way, if someone installs<br>> Python from source, or installs an experimental version of a new distro<br>
> Python, it won't break their system.</span></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">I agree. I would personally like it if distributions would provide a python utility that can be changed by the sysadmin without breaking anything, but implementing such a thing would be too much to ask from many distros, so I left it out of the first draft of the PEP. I'll put into the Notes in the second draft, though.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">Again, I think that the nature of the "python" utility is a decision that belongs squarely to the distributions (it'll likely evolve into an "everyone else is doing it" sort of issue for distros like Debian that don't like to change without good reason). On the other hand, ensuring that cross-platform support exists is an issue that should be handled by a central authority.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">I almost added provisions to the second draft of the PEP for things like "python2.6", since the same issue basically exists with them, so it would be logical to also address their support. However, since there are far fewer cases where minor version changes break code, and far more cases where a specific minor version of the Python interpreter isn't and doesn't need to be installed, I imagine a problem will occur if we make "pythonX.X" standard: developers will use the "pythonX.X" invocations instead of ensuring their code works on all (recent) versions of the interpreter, and much larger issues will arise when users are forced to repeatedly install different minor versions of the interpreter. I instead addressed this topic in the "Notes" section.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">-Kerrick Staley</span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font></div><div><div class="gmail_quote">On Thu, Mar 3, 2011 at 10:09 PM, Toshio Kuratomi <span dir="ltr"><<a href="mailto:a.badger@gmail.com" target="_blank">a.badger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:<br>
> On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:<br>
><br>
> >On a related note, we have a number of scripts packaged across the<br>
> >distributions with a shebang line that reads:<br>
> > #!/usr/bin/env python<br>
> >which AIUI follows upstream recommendations.<br>
><br>
> Actually, I think this is *not* a good idea for distro provided scripts. For<br>
> any Python scripts released by the distro, you know exactly which Python it<br>
> should run on, so it's better to hard code it. That way, if someone installs<br>
> Python from source, or installs an experimental version of a new distro<br>
> Python, it won't break their system. Yes, this has happened to me. Also,<br>
> note that distutils/setuptools/distribute rewrite the shebang line when they<br>
> install scripts.<br>
><br>
> >There was a proposal to change these when packaging them to hardcode the<br>
> >specific python binary:<br>
> ><br>
> ><a href="https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython" target="_blank">https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython</a><br>
> >on the grounds that a packaged system script is expecting (and has been<br>
> >tested against) a specific python build.<br>
> ><br>
> >That proposal has not yet been carried out. Ideally if we did this,<br>
> >we'd implement it as a postprocessing phase within "rpmbuild", rather<br>
> >than manually patching hundreds of files.<br>
> ><br>
> >Note that this would only cover shebang lines at the tops of scripts.<br>
><br>
> JFDI!<br>
><br>
> FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on<br>
> Ubuntu. We should fix these. ;)<br>
><br>
</div></div>Note, we were unable to pass Guideline changes to do this in Fedora. Gory<br>
details of the FPC meeting are at 16:15:03 (abadger1999 == me):<br>
<a href="http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html" target="_blank">http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html</a><br>
<br>
The mailing list thread where this was discussed is here:<br>
<a href="http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html" target="_blank">http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html</a><br>
<br>
Note to dmalcolm: IIRC, that also means that the Feature page you point to<br>
isn't going to happen either. Barry -- if other distros adopted stronger<br>
policies, then that might justify me taking this back to the Packaging<br>
Committee.<br>
<font color="#888888"><br>
-Toshio<br>
</font><br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com" target="_blank">http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com</a><br>
<br></blockquote></div><br></div>