On Fri, 23 Nov 2018 at 01:44, Petr Viktorin <encu...@gmail.com> wrote:
> On 11/22/18 1:34 PM, Nick Coghlan wrote:
> > - /usr/bin/python2 for scripts that definitely don't work on Python 3.x
> > - /usr/bin/python3 for scripts that definitely don't work on Python 2.x
> > - /usr/bin/python for single source scripts that seek broad
> > compatibility with older systems running Python 2.x
> > - /usr/bin/py for single source scripts that seek forward
> > compatibility with newer systems (and also with older systems that
> > have been configured to support it)
>
> But, by the time py is part of major distros, it'll be just as valid to
> just recommend /usr/bin/python3 here.

I'm looking for an approach that system administrators can apply as a
low-risk forward compatibility improvement on existing systems (even
truly ancient ones running Python versions even older than 2.7), as
even if LTS vendors accept the change as a reasonable forward
compatibility feature, it would still take at least months, and more
likely years, for it to reach an appreciable portion of their customer
base that way.

By contrast, a post-install modification to add an extra symlink if it
doesn't already exist can be handled as a routine part of baseline
operating environment definitions.

> If you need to support older
> systems that you can configure -- well, install Python 3 on them!

There's a few challenges with that perspective:

* Maintaining parallel Python stacks is complicated: if you add a
second Python interpreter to a system, you have to duplicate all the
Standard Operating Environment APIs as well (distro Python stack
maintainers hit that constraint pretty often). That's a much bigger
increase in complexity than giving the existing stack an additional
alias.
* Updates get bigger (including the size and frequency of security
updates): adding a new symlink is a minimal change to an image build
system (or config management system, or live system) with no long term
increase in maintenance burden. Adding a parallel Python 3 stack
increases the size of base images *and* the size and frequency of
ongoing updates to that system.
* Institutional approvals are harder to obtain: due to the increased
maintenance overhead and bandwidth usage of a full parallel stack,
institutional gatekeepers are going to be far more reluctant to
approve a parallel Python stack than they would be to approve a new
symlink pointing to their existing stack

If it weren't for those kinds of problems, the debates over how first
Fedora, and then EPEL and RHEL, were going to handle the parallel
maintenance question wouldn't have taken as long as they did.

Having a "/usr/bin/python3" symlink point to a Python 2.7 stack would
be a genuinely terrible idea (even more problematic than having
"/usr/bin/python" refer to Python 3.x), but we already have several
years of precedent in the Windows ecosystem that "/usr/bin/py" in a
shebang line refers to the common subset of Python 2.7 & 3.x, *not* to
one or the other.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
_______________________________________________
Linux-sig mailing list -- linux-sig@python.org
To unsubscribe send an email to linux-sig-le...@python.org
https://mail.python.org/mailman3/lists/linux-sig.python.org

Reply via email to