[Linux-SIG] Updating PEP 394 to recommend soft-linking python to python3 on newer distributions

[Jeremy Stanley]

On 2018-09-24 10:48:12 +0100 (+0100), Sorin Sbarnea wrote:
[...]
> Now almost all major distributions are switching to python3 by
> default and not installing python2 in their base deployment.
> 
> They also seem careful to follow PEP 394 which is a good thing to
> do. Still, the side effect of this is that based on that they do
> *not* create the symlink between python -> python3 which means a
> newly spawned machine would give "command not found" when trying
> to run `python`.
> 
> The lack of default breaks lots of tools which only need one
> python interpreter to run, regardless its version.
[...]

At least in Debian, they're looking at dropping the /usr/bin/python
symlink from future python2.7 packages, so as to get out of
appearing to define a "default Python interpreter version" and
allowing users to then supply their own if they see fit.

    https://lists.debian.org/debian-python/2018/05/msg00063.html

There is also strong sentiment within the Debian community against
ever supplying a /usr/bin/python which invokes python3, even once
they cease shipping a python2.7 interpreter entirely.

> One notable issue is Ansible where users would be forced to do
> extra steps for controlling new machines with only python3 on
> them. https://github.com/ansible/ansible/issues/45852
> <https://github.com/python/peps/pull/785> -- yep, not being able
> to cleanly run configuration management may create a chicken and
> the egg issue, as users would want to use it to configure the
> machine.

On servers which don't have Python installed into the global system
context, or where you want Ansible to invoke a particular
non-default interpreter installation, something like
ansible_python_interpreter would still be needed, right? (Think:
RHEL Software Collections.)

> Other examples are any scripts that now will not be able to ship
> with a generic shebang line. It would be impossible to make a
> generic python script executable to run on all platforms, even if
> the code itself would work without problems.

PEP 394 already allows bin/python in a Python 3.x virtual
environment to invoke python3. Distribution packaging similarly
works around these issues by patching shebang lines to refer to an
explicit major interpreter version. This does leave installing
sdists/wheels into the global system context as a broken use case,
but it's become increasingly popular within the Python packaging
community to declare that particular case dangerous and unsupported:

    https://github.com/pypa/pip/issues/4805#issuecomment-381404626

Also some distributions (e.g. Red Hat) have long held that the
system-provided Python interpreter is only intended for use by
Python-based applications shipped in the distribution itself, and
that if you have a need for a generic Python environment to run
arbitrary scripts you should install one in a non-system path.
They've traditionally introduced non-upstream behaviors into their
system Python interpreter in service of backporting newer versions
of software they've committed to support, so there's no guarantee it
will match the featureset for the claimed interpreter version
anyway.

> I may also mention the (in)famous usage of `curl <url> | python`
> approach which is popular.  Without having a "python" command,
> developers would have to update the documentation to mention the
> use of python or python3 based on the platform (creating more work
> which may be avoidable).
[...]

Maybe it's my security background, but I'd rather see that
anti-pattern die in a fire. If people don't even know what version
of Python they should tack on the end of that pipe, they almost
certainly shouldn't be running random scripts they find on the Web
through it. Also, if the idea is that more and more distros are no
longer shipping Python 2.x by default but _are_ shipping 3.x then
changing that to `... | python3` as the default recommendation seems
pretty simple to me (does still make my skin crawl though).

> Arch Linux made the decision to implement this regardless the PEP.
> Instead of going the path of ignoring it it, wouldn't be much
> better if we would improve it so it can be followed by everyone
> without clearly bad side-effects for the endusers?

I think most of the Python community has traditionally considered
the choice Arch foisted on their users to be a terrible and not at
all recommended configuration. I certainly wouldn't want to see it
propagated further.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/linux-sig/attachments/20180924/69f12c21/attachment.sig>