[oe] [RFC] Manage python symlinks with update-alternatives

[Andreas Oberritter]

Hi Andrey, everybody,

This was "[meta-oe][PATCH 1/3] pcsc-lite: update recipe to use python3", where I suggested to use update-alternatives for python.

I changed the topic in the hope of gaining a wider audience. Please don't skip the quoted text:

On Mon, 27 Jan 2020 23:42:50 +0100
Andrey Zhizhikin <andrey.z at gmail.com> wrote:

> Hi Andreas,
> 
> On Mon, Jan 27, 2020 at 9:16 PM Andreas Oberritter <obi at opendreambox.org> wrote:
> >
> > Hi Andrey,
> >
> > On Mon, 27 Jan 2020 17:36:06 +0000
> > Andrey Zhizhikin <andrey.z at gmail.com> wrote:
> > > +--- a/src/spy/pcsc-spy
> > > ++++ b/src/spy/pcsc-spy
> > > +@@ -1,4 +1,4 @@
> > > +-#! /usr/bin/python
> > > ++#!/usr/bin/env python3
> > > +
> > > + """
> > > + #    Display PC/SC functions arguments
> > > +@@ -22,12 +22,7 @@ from __future__ import print_function
> > > + import os
> > > + import signal
> > > + import time
> > > +-try:
> > > +-    # for Python3
> > > +-    from queue import Queue
> > > +-except ImportError:
> > > +-    # for Python2
> > > +-    from Queue import Queue
> > > ++from queue import Queue
> > > + from threading import Thread
> > > + from operator import attrgetter
> > > +
> > > +--
> > > +2.17.1
> > > +
> >
> > This patch would not have been necessary if we managed the python symlink with update-alternatives. I'm doing this in my layer. Maybe that would be a better way to go? I won't be able to build master in the next days or weeks, but if you want to try and submit it, here's what I have in my bbappends:
> >
> > python_%.bbappend:
> >
> > inherit update-alternatives
> >
> > ALTERNATIVE_${PN}-core = "python"
> > ALTERNATIVE_TARGET[python] = "${bindir}/python2"
> > ALTERNATIVE_PRIORITY = "2"
> >
> > do_install_append_class-target() {
> >     rm -f ${D}${bindir}/python
> > }
> >
> > python3_%.bbappend:
> >
> > inherit update-alternatives
> >
> > ALTERNATIVE_${PN}-core = "python"
> > ALTERNATIVE_TARGET[python] = "${bindir}/python3"
> > ALTERNATIVE_PRIORITY = "3"
> 
> That is an interesting suggestion... The only potential problem with
> this one I see is that when target would require to have both versions
> (2 and 3) then it might be interpreted wrong. This patch states
> explicitly that python3 is the interpreter of choice, with
> update-alternatives I would never be sure what would land up on my
> device.

In the case of your patch, this would have been no problem, because the patched
file had support for both Pythons.

From a distro owner's point of view, the priorities define which one gets
preferred.

This should be in line with PEP 394, and I think having a python symlink
always beats having none. :)

To explain the reasoning behind my approach a litte more: People want to write
Python scripts compatible with both new and old devices. Many old devices won't
ever get a Python 3 interpreter. It's possible to gain full compatibility on
a source code level, but you can never autodetect whether python2, python3 or
both are installed in $PATH with a single shebang. Also, people are already
used to not knowing whether python points to python2 or python3 (see Arch Linux).

Of course, many of you expect to have all scripts under control of OE, but what
I primarily have in mind are the device owners, who just copy over their scripts
with SSH.

Additionally, every patch that's not present in OE is a win for maintainability.

Best regards,
Andreas