[Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems
Gregory P. Smith
greg at krypto.org
Mon Feb 18 12:28:21 EST 2019
On Mon, Feb 18, 2019, 7:34 AM Matthias Klose <doko at ubuntu.com wrote:
> On 16.02.19 00:15, Gregory P. Smith wrote:
> > On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw <barry at python.org> wrote:
> >> On Feb 13, 2019, at 23:08, Matěj Cepl <mcepl at cepl.eu> wrote:
> >>> Is this relevant to the discussion at hand? We are talking about
> >>> the binary /usr/bin/python3 which will be surely be provided
> >>> even by Python 4, won't it?
> >> Why would it be? Since this is all hypothetical anyway <wink>, I’d more
> >> likely expect to only ship /usr/bin/python.
> > Because nobody can use 'python' and expect that to be anything but a
> > compatible interpreter for the next 5+ years given we live in a world
> > people routinely have a very real need to write #! lines that works with
> > obsolete distributions. python3 implies >=3.x, thus python 4, 5, 6,
> > 3001, and 90210 should all have python3 point to them. realistically
> > people will stop referring to python3 by 2069 so we could consider
> > the recommendation at that point.
> > 2020 is not the end of use or end of importance for Python 2. It is
> > the end of bugfixes applied by python-dev.
> > A thing I want to make sure we _don't_ do in the future is allow future
> > pythonN binaries. python4, python90210, etc. those should never exist.
> > python, python3, and pythonX.Y only. If we were ever to go back on our
> > promise and create another world-breaking python version, it could get
> > own canonical binary name. But we're specifically planning _not_ to make
> > that mistake again.
> > I suspect most of my opining below will be contentious to multiple people
> > because I describe a state of the world that is at conflict with
> > multiple independent distros have already made. Accept their mistakes
> > move on past it to the hack in that case:
> > A new "py" launcher isn't going to solve this problem - it is separate
> > should be its own PEP as it has its own set of requirements and reasons
> > be considered (especially on platforms with no concept of a #!).
> > "py" today-ish and nobody can rely on it for at least 10+ years in a wide
> > support cross platform scripting type of situation because it won't be
> > present on the obsolete or long term supported things that people have a
> > need for such #!s to run on.
> > Not our problem? Well, actually, it is. Matthias speaking for Debian
> > suggesting they don't want to have "python" at all if it isn't a synonym
> > for "python2" because it'll break software is... wrong. If software is
> > 3 compatible and uses "python", it'll also break when python is python3.
> > Just in a different manner. "python" should point to python3 when a
> > does not require python2 for its core. It should not _vary_ as to which
> > 2.7 or 3.7 it will point to within a given stable distribution
> > python2.7 should never suddenly redirect it back to python2). But
> > itself should always exist when any python interpreter is core to the OS.
> > That means if a distro no longer requires python2 as part of its
> > but does require python3... "python" must point to "python3". If a
> > OS no longer requires python at all (surely there are some by now?) the
> > question of what python should point to when an OS distro supplied
> > python package gets installed is likely either "nothing at all" or
> > but should never be decided as "2.7" (which sadly may be what macOS
> There is no notion of a "core" for Debian. So "core" applies to the whole
> distro, as long as there are python shebangs found.
> For Ubuntu, you don't have a python command on the default desktop
> install, just
> python3. Trying to invoke python, command-not-found tells you:
> $ python
> Command 'python' not found, but can be installed with:
> You also have python3 installed, you can run 'python3' instead.
> That tells you which way to go.
"Core" just means part of the minimal install, needed by startup scripts
and the package manager perhaps. This would be a default install with no
package groups selected or perhaps the netinst image for Debian. If
packages in that set don't need a python interpreter, Debian is in great
> > Do we already have LTS _stable_ distributions making that mistake today?
> > If so they've done something undesirable for the world at large and we're
> > already screwed if that distro release is deemed important by masses of
> > users: There is no way to write a *direct* #! line that works out of the
> > box to launch a working latest version Python interpreter across all
> > platforms.
> If you count the above example towards this "mistake", probably yes. But
> is *no* way to have a sane way to have what you want.
In the long run, expecting python 2 to exist is not sane. But given our
pep394 text of "for the time being, all distributions *should* ensure that
python, if installed, refers to the same target as python2," What Debian
has done is still unfortunately encouraged by us.
We've created a world where #! lines cannot be used to invoke an
intentionally compatible script across a wide variety of platforms over
time. But our decision to do that was the decision to have an incompatible
release in the first place.
Too late now. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev