> LGTM. Please specify what /usr/bin/python is supposed to be also
> (rather: the "python" utility). I'd like it ruled out that
> installations *only* provide python2 and python3 - "python" could
> be either one, but should be present "normally" (i.e. SHOULD
> in the RFC 2119 sense).
> 
> Nitpickingly, I'd add that scripts can, of course, also specify
> python2.7 (or some such). Actually, scripts can do whatever they
> want - it's more about what they then can expect to happen.
Good points--I've taken them into account in the revised PEP, which I will send to this list shortly.
> OTOH, my
> cynical side doubts that script authors read PEPs so it'll take either
> upstream python shipping without /usr/bin/python or consensus among the
> distros to ship without /usr/bin/python to reach the point where script
> authors realize that they need to use /usr/bin/python{2,3} instead of
> /usr/bin/python.
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.
> Actually, I think this is *not* a good idea for distro provided scripts.  For
> any Python scripts released by the distro, you know exactly which Python it
> should run on, so it's better to hard code it.  That way, if someone installs
> Python from source, or installs an experimental version of a new distro
> Python, it won't break their system.
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.

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.

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.

-Kerrick Staley

On Thu, Mar 3, 2011 at 10:09 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
On Thu, Mar 03, 2011 at 09:11:40PM -0500, Barry Warsaw wrote:
> On Mar 03, 2011, at 02:17 PM, David Malcolm wrote:
>
> >On a related note, we have a number of scripts packaged across the
> >distributions with a shebang line that reads:
> >   #!/usr/bin/env python
> >which AIUI follows upstream recommendations.
>
> Actually, I think this is *not* a good idea for distro provided scripts.  For
> any Python scripts released by the distro, you know exactly which Python it
> should run on, so it's better to hard code it.  That way, if someone installs
> Python from source, or installs an experimental version of a new distro
> Python, it won't break their system.  Yes, this has happened to me.  Also,
> note that distutils/setuptools/distribute rewrite the shebang line when they
> install scripts.
>
> >There was a proposal to change these when packaging them to hardcode the
> >specific python binary:
> >
> >https://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython
> >on the grounds that a packaged system script is expecting (and has been
> >tested against) a specific python build.
> >
> >That proposal has not yet been carried out.  Ideally if we did this,
> >we'd implement it as a postprocessing phase within "rpmbuild", rather
> >than manually patching hundreds of files.
> >
> >Note that this would only cover shebang lines at the tops of scripts.
>
> JFDI!
>
> FWIW, a quick grep reveals about two dozen such scripts in /usr/bin on
> Ubuntu.  We should fix these. ;)
>
Note, we were unable to pass Guideline changes to do this in Fedora.  Gory
details of the FPC meeting are at 16:15:03 (abadger1999 == me):
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html

The mailing list thread where this was discussed is here:
http://lists.fedoraproject.org/pipermail/packaging/2009-July/006248.html

Note to dmalcolm: IIRC, that also means that the Feature page you point to
isn't going to happen either.  Barry -- if other distros adopted stronger
policies, then that might justify me taking this back to the Packaging
Committee.

-Toshio

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.com