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
