> 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.bad...@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
>
>
_______________________________________________
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/archive%40mail-archive.com
