[scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[jiaying.song.cn]

From: Jiaying Song <jiaying.song.cn@windriver.com>

The /usr/bin/python cannot find the correct Python interpreter, so a symbolic
link is added to point it to the Python3 interpreter.

Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
---
 meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
 meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json b/meta/recipes-devtools/python/python3/python3-manifest.json
index 46092d4004..f9259e1450 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -220,6 +220,7 @@
         "files": [
             "${bindir}/python${PYTHON_MAJMIN}",
             "${bindir}/python${PYTHON_MAJMIN}.real",
+            "${bindir}/python",
             "${bindir}/python3",
             "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
             "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
diff --git a/meta/recipes-devtools/python/python3_3.12.4.bb b/meta/recipes-devtools/python/python3_3.12.4.bb
index 743ba0b1f1..94535e7678 100644
--- a/meta/recipes-devtools/python/python3_3.12.4.bb
+++ b/meta/recipes-devtools/python/python3_3.12.4.bb
@@ -165,6 +165,7 @@ do_install:prepend() {
 
 do_install:append:class-target() {
         oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
+        ln -sf ${bindir}/python3 ${D}${bindir}/python
 }
 
 do_install:append:class-native() {
-- 
2.44.0

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Denys Dmytriyenko]

Should this be done via update-alternatives, like many other Linux distros do?


On Wed, Jul 17, 2024 at 10:32:01AM +0800, Song, Jiaying (CN) via lists.openembedded.org wrote:
> From: Jiaying Song <jiaying.song.cn@windriver.com>
> 
> The /usr/bin/python cannot find the correct Python interpreter, so a symbolic
> link is added to point it to the Python3 interpreter.
> 
> Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
> ---
>  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
>  meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json b/meta/recipes-devtools/python/python3/python3-manifest.json
> index 46092d4004..f9259e1450 100644
> --- a/meta/recipes-devtools/python/python3/python3-manifest.json
> +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
> @@ -220,6 +220,7 @@
>          "files": [
>              "${bindir}/python${PYTHON_MAJMIN}",
>              "${bindir}/python${PYTHON_MAJMIN}.real",
> +            "${bindir}/python",
>              "${bindir}/python3",
>              "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
>              "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
> diff --git a/meta/recipes-devtools/python/python3_3.12.4.bb b/meta/recipes-devtools/python/python3_3.12.4.bb
> index 743ba0b1f1..94535e7678 100644
> --- a/meta/recipes-devtools/python/python3_3.12.4.bb
> +++ b/meta/recipes-devtools/python/python3_3.12.4.bb
> @@ -165,6 +165,7 @@ do_install:prepend() {
>  
>  do_install:append:class-target() {
>          oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
> +        ln -sf ${bindir}/python3 ${D}${bindir}/python
>  }
>  
>  do_install:append:class-native() {
> -- 
> 2.44.0

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

But there is no alternative. Python is python3 and has been for years.

Alex

On Fri 19. Jul 2024 at 0.47, Denys Dmytriyenko <denis@denix.org> wrote:

> Should this be done via update-alternatives, like many other Linux distros
> do?
>
>
> On Wed, Jul 17, 2024 at 10:32:01AM +0800, Song, Jiaying (CN) via
> lists.openembedded.org wrote:
> > From: Jiaying Song <jiaying.song.cn@windriver.com>
> >
> > The /usr/bin/python cannot find the correct Python interpreter, so a
> symbolic
> > link is added to point it to the Python3 interpreter.
> >
> > Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
> > ---
> >  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
> >  meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
> b/meta/recipes-devtools/python/python3/python3-manifest.json
> > index 46092d4004..f9259e1450 100644
> > --- a/meta/recipes-devtools/python/python3/python3-manifest.json
> > +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
> > @@ -220,6 +220,7 @@
> >          "files": [
> >              "${bindir}/python${PYTHON_MAJMIN}",
> >              "${bindir}/python${PYTHON_MAJMIN}.real",
> > +            "${bindir}/python",
> >              "${bindir}/python3",
> >              "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
> >              "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
> > diff --git a/meta/recipes-devtools/python/python3_3.12.4.bb
> b/meta/recipes-devtools/python/python3_3.12.4.bb
> > index 743ba0b1f1..94535e7678 100644
> > --- a/meta/recipes-devtools/python/python3_3.12.4.bb
> > +++ b/meta/recipes-devtools/python/python3_3.12.4.bb
> > @@ -165,6 +165,7 @@ do_install:prepend() {
> >
> >  do_install:append:class-target() {
> >          oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
> > +        ln -sf ${bindir}/python3 ${D}${bindir}/python
> >  }
> >
> >  do_install:append:class-native() {
> > --
> > 2.44.0
>

[-- Attachment #2: Type: text/html, Size: 3367 bytes --]

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]

There was a proposal with two option (maybe that was missed) and I
suggested just adding the link and be done with it. We can drop lots of
patches and send tweaks then.

Alex

On Fri 19. Jul 2024 at 8.17, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> But there is no alternative. Python is python3 and has been for years.
>
> Alex
>
> On Fri 19. Jul 2024 at 0.47, Denys Dmytriyenko <denis@denix.org> wrote:
>
>> Should this be done via update-alternatives, like many other Linux
>> distros do?
>>
>>
>> On Wed, Jul 17, 2024 at 10:32:01AM +0800, Song, Jiaying (CN) via
>> lists.openembedded.org wrote:
>> > From: Jiaying Song <jiaying.song.cn@windriver.com>
>> >
>> > The /usr/bin/python cannot find the correct Python interpreter, so a
>> symbolic
>> > link is added to point it to the Python3 interpreter.
>> >
>> > Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
>> > ---
>> >  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
>> >  meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
>> >  2 files changed, 2 insertions(+)
>> >
>> > diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
>> b/meta/recipes-devtools/python/python3/python3-manifest.json
>> > index 46092d4004..f9259e1450 100644
>> > --- a/meta/recipes-devtools/python/python3/python3-manifest.json
>> > +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
>> > @@ -220,6 +220,7 @@
>> >          "files": [
>> >              "${bindir}/python${PYTHON_MAJMIN}",
>> >              "${bindir}/python${PYTHON_MAJMIN}.real",
>> > +            "${bindir}/python",
>> >              "${bindir}/python3",
>> >              "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
>> >              "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
>> > diff --git a/meta/recipes-devtools/python/python3_3.12.4.bb
>> b/meta/recipes-devtools/python/python3_3.12.4.bb
>> > index 743ba0b1f1..94535e7678 100644
>> > --- a/meta/recipes-devtools/python/python3_3.12.4.bb
>> > +++ b/meta/recipes-devtools/python/python3_3.12.4.bb
>> > @@ -165,6 +165,7 @@ do_install:prepend() {
>> >
>> >  do_install:append:class-target() {
>> >          oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
>> > +        ln -sf ${bindir}/python3 ${D}${bindir}/python
>> >  }
>> >
>> >  do_install:append:class-native() {
>> > --
>> > 2.44.0
>>
>

[-- Attachment #2: Type: text/html, Size: 4021 bytes --]

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Denys Dmytriyenko]

On Fri, Jul 19, 2024 at 08:18:26AM +0200, Alexander Kanavin wrote:
> There was a proposal with two option (maybe that was missed) and I

Yeah, I guess I missed that one.


> suggested just adding the link and be done with it. We can drop lots of
> patches and send tweaks then.
> 
> Alex
> 
> On Fri 19. Jul 2024 at 8.17, Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
> 
> > But there is no alternative. Python is python3 and has been for years.

Understood, but many distros still manage symlinks via update-alternatives, 
hence my question. I guess since we don't supoort multiple versions at the 
same time, it does make sense to keep it simple...


> > Alex
> >
> > On Fri 19. Jul 2024 at 0.47, Denys Dmytriyenko <denis@denix.org> wrote:
> >
> >> Should this be done via update-alternatives, like many other Linux
> >> distros do?
> >>
> >>
> >> On Wed, Jul 17, 2024 at 10:32:01AM +0800, Song, Jiaying (CN) via
> >> lists.openembedded.org wrote:
> >> > From: Jiaying Song <jiaying.song.cn@windriver.com>
> >> >
> >> > The /usr/bin/python cannot find the correct Python interpreter, so a
> >> symbolic
> >> > link is added to point it to the Python3 interpreter.
> >> >
> >> > Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
> >> > ---
> >> >  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
> >> >  meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
> >> >  2 files changed, 2 insertions(+)
> >> >
> >> > diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json
> >> b/meta/recipes-devtools/python/python3/python3-manifest.json
> >> > index 46092d4004..f9259e1450 100644
> >> > --- a/meta/recipes-devtools/python/python3/python3-manifest.json
> >> > +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
> >> > @@ -220,6 +220,7 @@
> >> >          "files": [
> >> >              "${bindir}/python${PYTHON_MAJMIN}",
> >> >              "${bindir}/python${PYTHON_MAJMIN}.real",
> >> > +            "${bindir}/python",
> >> >              "${bindir}/python3",
> >> >              "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
> >> >              "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
> >> > diff --git a/meta/recipes-devtools/python/python3_3.12.4.bb
> >> b/meta/recipes-devtools/python/python3_3.12.4.bb
> >> > index 743ba0b1f1..94535e7678 100644
> >> > --- a/meta/recipes-devtools/python/python3_3.12.4.bb
> >> > +++ b/meta/recipes-devtools/python/python3_3.12.4.bb
> >> > @@ -165,6 +165,7 @@ do_install:prepend() {
> >> >
> >> >  do_install:append:class-target() {
> >> >          oe_multilib_header python${PYTHON_MAJMIN}/pyconfig.h
> >> > +        ln -sf ${bindir}/python3 ${D}${bindir}/python
> >> >  }
> >> >
> >> >  do_install:append:class-native() {
> >> > --
> >> > 2.44.0
> >>
> >

Re: [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Konrad Weihmann]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

I also vote against it.

While I see the convenience in dropping a lot of patches the better approach would be to add something like python-is-python3, for the ones that require it.
(meta-webkit does provide it already https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb ).

Adding a link by the base package and recommending to the user to remove it again, would create two very unwelcome situations.

a) it will clash at image assembly with an error message that will no easily point to the python base package
b) create a need to run with a permanent remove operation on top of poky (creating the need for new sstate cache artifacts)

What I could see is to move the symlink into an optional package, which could be used by the few recipes that still use the "wrong" interpreter line via RDEPENDS, that would be the much cleaner solution here

[-- Attachment #2: Type: text/html, Size: 1113 bytes --]

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Randy MacLeod]

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote:
> I also vote against it.

I'm on the fence but I'll be swayed by the "against" voters.

There are pros and cons to a system-wide solution but it seems that
people prefer to have these problems fixed in each affected recipe.
Best solution is to update the script to call and work with python3.
If the upstream refuses to do that, the layer would have to carry a patch.

This is how most such '/usr/bin/python' problems have been solved.
It's a shame that upstream python didn't mandate a specific solution.

Btw, some people could use:

https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb
https://github.com/Igalia/meta-webkit/commit/b2156c282a6e727100dee25155fbc38d1532b573
https://github.com/Igalia/meta-webkit/commit/46fbfbc58f82abc3dc8794c630172d4554be0830

❯ git log --stat 46fbfbc5
commit 46fbfbc58f82abc3dc8794c630172d4554be0830
Author: Carlos Alberto Lopez Perez <clopez@igalia.com>
Date:   Mon Dec 19 20:29:05 2022

     Add a new image and distro definition for using on the WebKit CI 
for WPE perf bots

  ...

     * It adds also a 'python-is-python3' recipe that creates a symlink
     to provide the unversioned python interpreter as python3.


but both oe-core and meta-oe maintainers said on today's YP tech call that
they would *not* carry that recipe.

../Randy



>
> While I see the convenience in dropping a lot of patches the better 
> approach would be to add something like python-is-python3, for the 
> ones that require it.
> (meta-webkit does provide it already 
> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb).
>
> Adding a link by the base package and recommending to the user to 
> remove it again, would create two very unwelcome situations.
>
> a) it will clash at image assembly with an error message that will no 
> easily point to the python base package
> b) create a need to run with a permanent remove operation on top of 
> poky (creating the need for new sstate cache artifacts)
>
> What I could see is to move the symlink into an optional package, 
> which could be used by the few recipes that still use the "wrong" 
> interpreter line via RDEPENDS, that would be the much cleaner solution 
> here
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#202364):https://lists.openembedded.org/g/openembedded-core/message/202364
> Mute This Topic:https://lists.openembedded.org/mt/107264938/3616765
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub  [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 5342 bytes --]

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

I guess the recommendation to remove the symlink if needed was a bit
poorly thought out.

On the other hand, I fail to see any benefit whatsoever in a separate
python-is-python3. If you do not have python 2.x installed on target,
there is no difference in whether there is a python symlink on the
target or not. And if you do, you still have the same clash between
2.x scripts that refer to python, and 3.x scripts that refer to
python, and no easy way to resolve that clash.

What I am proposing instead is this:

- python to python3 symlink is still provided by the base package.
It's not accurate to say that 'patching' things from recipes to use
python3 is what people 'prefer', it's that up until now they were
forced to do it, Randy.

- if anyone is still using python 2.x in target images in 2024 with
yocto master (nevermind that the public python2 layer is dead and
unmaintained), and is relying on python 2.x being symlinked to python,
they should be adjusting their scripts to point to python2 instead.
They no longer own the unversioned python symlink and we should not be
catering to them.

Please reframe your arguments.

Alex

On Tue, 23 Jul 2024 at 18:44, Randy MacLeod via lists.openembedded.org
<randy.macleod=windriver.com@lists.openembedded.org> wrote:
>
> On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote:
>
> I also vote against it.
>
> I'm on the fence but I'll be swayed by the "against" voters.
>
> There are pros and cons to a system-wide solution but it seems that
> people prefer to have these problems fixed in each affected recipe.
> Best solution is to update the script to call and work with python3.
> If the upstream refuses to do that, the layer would have to carry a patch.
>
> This is how most such '/usr/bin/python' problems have been solved.
> It's a shame that upstream python didn't mandate a specific solution.
>
> Btw, some people could use:
>
> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb
> https://github.com/Igalia/meta-webkit/commit/b2156c282a6e727100dee25155fbc38d1532b573
> https://github.com/Igalia/meta-webkit/commit/46fbfbc58f82abc3dc8794c630172d4554be0830
>
> ❯ git log --stat 46fbfbc5
> commit 46fbfbc58f82abc3dc8794c630172d4554be0830
> Author: Carlos Alberto Lopez Perez <clopez@igalia.com>
> Date:   Mon Dec 19 20:29:05 2022
>
>     Add a new image and distro definition for using on the WebKit CI for WPE perf bots
>
>  ...
>
>     * It adds also a 'python-is-python3' recipe that creates a symlink
>     to provide the unversioned python interpreter as python3.
>
>
> but both oe-core and meta-oe maintainers said on today's YP tech call that
> they would *not* carry that recipe.
>
> ../Randy
>
>
>
>
> While I see the convenience in dropping a lot of patches the better approach would be to add something like python-is-python3, for the ones that require it.
> (meta-webkit does provide it already https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb).
>
> Adding a link by the base package and recommending to the user to remove it again, would create two very unwelcome situations.
>
> a) it will clash at image assembly with an error message that will no easily point to the python base package
> b) create a need to run with a permanent remove operation on top of poky (creating the need for new sstate cache artifacts)
>
> What I could see is to move the symlink into an optional package, which could be used by the few recipes that still use the "wrong" interpreter line via RDEPENDS, that would be the much cleaner solution here
>
>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#202412): https://lists.openembedded.org/g/openembedded-core/message/202412
> Mute This Topic: https://lists.openembedded.org/mt/107264938/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Konrad Weihmann]

How about just moving it to an additional package out of the python recipe.
It's almost zero effort to implement and zero effort to maintain, while 
not deliberately breaking builds (it's not that the users I know are 
keen on keeping python2).

basically a PACKAGE_BEFORE_PN = "python3-python-symlink" + 
FILES:python3-python-symlink += "${bindir}/python" will do it.

And those lines will most likely never ever change again.

Like this it at least allows a RCONFLICTS to be properly propagated.

Followups could then replace the unanswered/rejects patches by 
RDEPENDing on that new package.
This will also help to maintain visibility on the problem.


On 23.07.24 19:56, Alexander Kanavin wrote:
> I guess the recommendation to remove the symlink if needed was a bit
> poorly thought out.
> 
> On the other hand, I fail to see any benefit whatsoever in a separate
> python-is-python3. If you do not have python 2.x installed on target,
> there is no difference in whether there is a python symlink on the
> target or not. And if you do, you still have the same clash between
> 2.x scripts that refer to python, and 3.x scripts that refer to
> python, and no easy way to resolve that clash.
> 
> What I am proposing instead is this:
> 
> - python to python3 symlink is still provided by the base package.
> It's not accurate to say that 'patching' things from recipes to use
> python3 is what people 'prefer', it's that up until now they were
> forced to do it, Randy.
> 
> - if anyone is still using python 2.x in target images in 2024 with
> yocto master (nevermind that the public python2 layer is dead and
> unmaintained), and is relying on python 2.x being symlinked to python,
> they should be adjusting their scripts to point to python2 instead.
> They no longer own the unversioned python symlink and we should not be
> catering to them.
> 
> Please reframe your arguments.
> 
> Alex
> 
> On Tue, 23 Jul 2024 at 18:44, Randy MacLeod via lists.openembedded.org
> <randy.macleod=windriver.com@lists.openembedded.org> wrote:
>>
>> On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote:
>>
>> I also vote against it.
>>
>> I'm on the fence but I'll be swayed by the "against" voters.
>>
>> There are pros and cons to a system-wide solution but it seems that
>> people prefer to have these problems fixed in each affected recipe.
>> Best solution is to update the script to call and work with python3.
>> If the upstream refuses to do that, the layer would have to carry a patch.
>>
>> This is how most such '/usr/bin/python' problems have been solved.
>> It's a shame that upstream python didn't mandate a specific solution.
>>
>> Btw, some people could use:
>>
>> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb
>> https://github.com/Igalia/meta-webkit/commit/b2156c282a6e727100dee25155fbc38d1532b573
>> https://github.com/Igalia/meta-webkit/commit/46fbfbc58f82abc3dc8794c630172d4554be0830
>>
>> ❯ git log --stat 46fbfbc5
>> commit 46fbfbc58f82abc3dc8794c630172d4554be0830
>> Author: Carlos Alberto Lopez Perez <clopez@igalia.com>
>> Date:   Mon Dec 19 20:29:05 2022
>>
>>      Add a new image and distro definition for using on the WebKit CI for WPE perf bots
>>
>>   ...
>>
>>      * It adds also a 'python-is-python3' recipe that creates a symlink
>>      to provide the unversioned python interpreter as python3.
>>
>>
>> but both oe-core and meta-oe maintainers said on today's YP tech call that
>> they would *not* carry that recipe.
>>
>> ../Randy
>>
>>
>>
>>
>> While I see the convenience in dropping a lot of patches the better approach would be to add something like python-is-python3, for the ones that require it.
>> (meta-webkit does provide it already https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb).
>>
>> Adding a link by the base package and recommending to the user to remove it again, would create two very unwelcome situations.
>>
>> a) it will clash at image assembly with an error message that will no easily point to the python base package
>> b) create a need to run with a permanent remove operation on top of poky (creating the need for new sstate cache artifacts)
>>
>> What I could see is to move the symlink into an optional package, which could be used by the few recipes that still use the "wrong" interpreter line via RDEPENDS, that would be the much cleaner solution here
>>
>>
>>
>>
>> --
>> # Randy MacLeod
>> # Wind River Linux
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#202412): https://lists.openembedded.org/g/openembedded-core/message/202412
>> Mute This Topic: https://lists.openembedded.org/mt/107264938/1686489
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

But why a separate package? I don't understand why people keep
insisting on it. There's no problem and no need to give it visibility,
there's just historical baggage that we can now fix. We can just add
the symlink from core package, drop all the sed hacks and rejected
upstream patches (instead of tweaking RDEPENDS), and the only people
affected would be those mysterious python 2.x users who would have to
patch *their* scripts instead, as they should be in 2024, so that
*they* know it's way past time to get rid of 2.x.

Master can and does break builds deliberately. There's not ever a
promise to not do that.

Alex

On Tue, 23 Jul 2024 at 20:19, Konrad Weihmann <kweihmann@outlook.com> wrote:
>
> How about just moving it to an additional package out of the python recipe.
> It's almost zero effort to implement and zero effort to maintain, while
> not deliberately breaking builds (it's not that the users I know are
> keen on keeping python2).
>
> basically a PACKAGE_BEFORE_PN = "python3-python-symlink" +
> FILES:python3-python-symlink += "${bindir}/python" will do it.
>
> And those lines will most likely never ever change again.
>
> Like this it at least allows a RCONFLICTS to be properly propagated.
>
> Followups could then replace the unanswered/rejects patches by
> RDEPENDing on that new package.
> This will also help to maintain visibility on the problem.
>
>
> On 23.07.24 19:56, Alexander Kanavin wrote:
> > I guess the recommendation to remove the symlink if needed was a bit
> > poorly thought out.
> >
> > On the other hand, I fail to see any benefit whatsoever in a separate
> > python-is-python3. If you do not have python 2.x installed on target,
> > there is no difference in whether there is a python symlink on the
> > target or not. And if you do, you still have the same clash between
> > 2.x scripts that refer to python, and 3.x scripts that refer to
> > python, and no easy way to resolve that clash.
> >
> > What I am proposing instead is this:
> >
> > - python to python3 symlink is still provided by the base package.
> > It's not accurate to say that 'patching' things from recipes to use
> > python3 is what people 'prefer', it's that up until now they were
> > forced to do it, Randy.
> >
> > - if anyone is still using python 2.x in target images in 2024 with
> > yocto master (nevermind that the public python2 layer is dead and
> > unmaintained), and is relying on python 2.x being symlinked to python,
> > they should be adjusting their scripts to point to python2 instead.
> > They no longer own the unversioned python symlink and we should not be
> > catering to them.
> >
> > Please reframe your arguments.
> >
> > Alex
> >
> > On Tue, 23 Jul 2024 at 18:44, Randy MacLeod via lists.openembedded.org
> > <randy.macleod=windriver.com@lists.openembedded.org> wrote:
> >>
> >> On 2024-07-23 9:38 a.m., Konrad Weihmann via lists.openembedded.org wrote:
> >>
> >> I also vote against it.
> >>
> >> I'm on the fence but I'll be swayed by the "against" voters.
> >>
> >> There are pros and cons to a system-wide solution but it seems that
> >> people prefer to have these problems fixed in each affected recipe.
> >> Best solution is to update the script to call and work with python3.
> >> If the upstream refuses to do that, the layer would have to carry a patch.
> >>
> >> This is how most such '/usr/bin/python' problems have been solved.
> >> It's a shame that upstream python didn't mandate a specific solution.
> >>
> >> Btw, some people could use:
> >>
> >> https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb
> >> https://github.com/Igalia/meta-webkit/commit/b2156c282a6e727100dee25155fbc38d1532b573
> >> https://github.com/Igalia/meta-webkit/commit/46fbfbc58f82abc3dc8794c630172d4554be0830
> >>
> >> ❯ git log --stat 46fbfbc5
> >> commit 46fbfbc58f82abc3dc8794c630172d4554be0830
> >> Author: Carlos Alberto Lopez Perez <clopez@igalia.com>
> >> Date:   Mon Dec 19 20:29:05 2022
> >>
> >>      Add a new image and distro definition for using on the WebKit CI for WPE perf bots
> >>
> >>   ...
> >>
> >>      * It adds also a 'python-is-python3' recipe that creates a symlink
> >>      to provide the unversioned python interpreter as python3.
> >>
> >>
> >> but both oe-core and meta-oe maintainers said on today's YP tech call that
> >> they would *not* carry that recipe.
> >>
> >> ../Randy
> >>
> >>
> >>
> >>
> >> While I see the convenience in dropping a lot of patches the better approach would be to add something like python-is-python3, for the ones that require it.
> >> (meta-webkit does provide it already https://github.com/Igalia/meta-webkit/blob/main/recipes-devtools/python/python-is-python3_1.0.bb).
> >>
> >> Adding a link by the base package and recommending to the user to remove it again, would create two very unwelcome situations.
> >>
> >> a) it will clash at image assembly with an error message that will no easily point to the python base package
> >> b) create a need to run with a permanent remove operation on top of poky (creating the need for new sstate cache artifacts)
> >>
> >> What I could see is to move the symlink into an optional package, which could be used by the few recipes that still use the "wrong" interpreter line via RDEPENDS, that would be the much cleaner solution here
> >>
> >>
> >>
> >>
> >> --
> >> # Randy MacLeod
> >> # Wind River Linux
> >>
> >>
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >> Links: You receive all messages sent to this group.
> >> View/Reply Online (#202412): https://lists.openembedded.org/g/openembedded-core/message/202412
> >> Mute This Topic: https://lists.openembedded.org/mt/107264938/1686489
> >> Group Owner: openembedded-core+owner@lists.openembedded.org
> >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >>

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Randy MacLeod]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

On 2024-07-23 1:56 p.m., Alexander Kanavin wrote:
> - if anyone is still using python 2.x in target images in 2024 with
> yocto master (nevermind that the public python2 layer is dead and
> unmaintained), and is relying on python 2.x being symlinked to python,
No one that I know if is doing this.
> they should be adjusting their scripts to point to python2 instead.
Yes, this is what I was recommending or at least what I was intending to 
recommend.

-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Richard Purdie]

On Wed, 2024-07-17 at 10:32 +0800, Song, Jiaying (CN) via lists.openembedded.org wrote:
> From: Jiaying Song <jiaying.song.cn@windriver.com>
> 
> The /usr/bin/python cannot find the correct Python interpreter, so a symbolic
> link is added to point it to the Python3 interpreter.
> 
> Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
> ---
>  meta/recipes-devtools/python/python3/python3-manifest.json | 1 +
>  meta/recipes-devtools/python/python3_3.12.4.bb             | 1 +
>  2 files changed, 2 insertions(+)

There is a bit of a debate around this change. 

We're at a point where we patch anything using "python" to use python3.
This puts us in a fairly good deterministic position where everything
is explicit.

If we add this patch, on the plus side, we can drop some of the patches
we're carrying but we also lose the markup of the python versions. If
there ever was a python4, we'd be back in a mess again.

Adding it, starts discussions about whether it should just be present
unconditionally or whether it should be a configurable link with
update-alternatives. Should it be a separate recipe? Should any recipe
using "python" without a version have a specific dependency on this new
recipe/package?

Having listened to the discussions and given this is pretty much a
solved problem for the majority of our current metadata, I'm in favour
of maintaining the status quo and not taking this change, even if we
have to carry a few patches. It does at least make the situation quite
clear and explicit.

Cheers,

Richard

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

On Wed, 24 Jul 2024 at 18:01, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

> Having listened to the discussions and given this is pretty much a
> solved problem for the majority of our current metadata, I'm in favour
> of maintaining the status quo and not taking this change, even if we
> have to carry a few patches. It does at least make the situation quite
> clear and explicit.

I'm fine with this. We have significantly bigger issues in oe-core
(e.g. the rust situation where the slide behind upstream is constantly
growing).

I think the really correct solution is a coordinated effort by common
distributions to convince python upstream to add the symlink directly
in cpython installation. Or make an official statement that it is not
going to happen, which would explicitly mean that scripts *have* to be
written with python3 shebang.

Alex

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Martin Jansa]

Doesn't https://peps.python.org/pep-0394/ recommend the current status
quo anyway?

Distributors may choose to set the behavior of the python command as follows:
python2,
python3,
not provide python command, allow python to be configurable by an end
user or a system administrator.

When packaging third party Python scripts, distributors are encouraged
to change less specific shebangs to more specific ones. This ensures
software is used with the latest version of Python available, and it
can remove a dependency on Python 2. The details on what specifics to
set are left to the distributors; though. Example specifics could
include:
Changing python shebangs to python3 when Python 3.x is supported.
Changing python shebangs to python2 when Python 3.x is not yet supported.
Changing python3 shebangs to python3.8 if the software is built with Python 3.8.

My preference would be to keep it as is and not merge this change as RP said.

If we drop the patches then we go against the recommendation to use
more specific shebangs and if we don't drop them then
python-is-python3 recipes or package shouldn't be needed.

Cheers,

On Wed, Jul 24, 2024 at 6:18 PM Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Wed, 24 Jul 2024 at 18:01, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > Having listened to the discussions and given this is pretty much a
> > solved problem for the majority of our current metadata, I'm in favour
> > of maintaining the status quo and not taking this change, even if we
> > have to carry a few patches. It does at least make the situation quite
> > clear and explicit.
>
> I'm fine with this. We have significantly bigger issues in oe-core
> (e.g. the rust situation where the slide behind upstream is constantly
> growing).
>
> I think the really correct solution is a coordinated effort by common
> distributions to convince python upstream to add the symlink directly
> in cpython installation. Or make an official statement that it is not
> going to happen, which would explicitly mean that scripts *have* to be
> written with python3 shebang.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#202465): https://lists.openembedded.org/g/openembedded-core/message/202465
> Mute This Topic: https://lists.openembedded.org/mt/107264938/3617156
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [martin.jansa@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3

[Alexander Kanavin]

This pep is old, and was written back when python 2.x was actively
used and supported. It says: 'we messed this up, we won't make
specific decisions or recommendations, we leave it up to distros to
set the policy and sort the mess'.

I think it's time upstream makes a decision about providing python
symlink directly upstream and writes a new pep. But I won't try to
convince them.

Alex

On Wed, 24 Jul 2024 at 18:36, Martin Jansa <martin.jansa@gmail.com> wrote:
>
> Doesn't https://peps.python.org/pep-0394/ recommend the current status
> quo anyway?
>
> Distributors may choose to set the behavior of the python command as follows:
> python2,
> python3,
> not provide python command, allow python to be configurable by an end
> user or a system administrator.
>
> When packaging third party Python scripts, distributors are encouraged
> to change less specific shebangs to more specific ones. This ensures
> software is used with the latest version of Python available, and it
> can remove a dependency on Python 2. The details on what specifics to
> set are left to the distributors; though. Example specifics could
> include:
> Changing python shebangs to python3 when Python 3.x is supported.
> Changing python shebangs to python2 when Python 3.x is not yet supported.
> Changing python3 shebangs to python3.8 if the software is built with Python 3.8.
>
> My preference would be to keep it as is and not merge this change as RP said.
>
> If we drop the patches then we go against the recommendation to use
> more specific shebangs and if we don't drop them then
> python-is-python3 recipes or package shouldn't be needed.
>
> Cheers,
>
> On Wed, Jul 24, 2024 at 6:18 PM Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> >
> > On Wed, 24 Jul 2024 at 18:01, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >
> > > Having listened to the discussions and given this is pretty much a
> > > solved problem for the majority of our current metadata, I'm in favour
> > > of maintaining the status quo and not taking this change, even if we
> > > have to carry a few patches. It does at least make the situation quite
> > > clear and explicit.
> >
> > I'm fine with this. We have significantly bigger issues in oe-core
> > (e.g. the rust situation where the slide behind upstream is constantly
> > growing).
> >
> > I think the really correct solution is a coordinated effort by common
> > distributions to convince python upstream to add the symlink directly
> > in cpython installation. Or make an official statement that it is not
> > going to happen, which would explicitly mean that scripts *have* to be
> > written with python3 shebang.
> >
> > Alex
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#202465): https://lists.openembedded.org/g/openembedded-core/message/202465
> > Mute This Topic: https://lists.openembedded.org/mt/107264938/3617156
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [martin.jansa@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >