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 _______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
