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

[Matthias Klose]

On 24.09.2018 16:33, Jeremy Stanley wrote:
> 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.

Right, Debian doesn't want to re-use the "python" binary name pointing to
python3.  For Ubuntu, I can propose a change, once we stop shipping packages
relying on the python shebang.  However that wouldn't be before within a few years.

>> 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

pip still unfortunately allows you to install and remove dpkg/rpm based
installations, and with the pypi prominent suggestion to use pip install
everywhere, that probably doesn't get better.

Matthias