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

[Khem Raj]

On Mon, Jan 27, 2020 at 3:45 PM Andreas Oberritter <obi at opendreambox.org> wrote:
>
> 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. :)
>

I differ slightly and would like to not create python symlink
intentionally, so we can
find and fix the needed packages. python2 is on its way out and
python4 doesn't yet exist
so, packages while so far have maintained backward compatibility with py2 might
not want to carry that along and would be open to use python3 explicitly so they
might be upstreamable patches as well.

> 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
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel