On Thu, 2020-08-27 at 13:42 +0200, Olaf Hering wrote:

Am Fri, 17 Jul 2020 10:44:58 -0400 schrieb Neal Gompa :

...

We still have a concept of a *default* Python version and things will just *work* that way?

Do we plan to have one? If yes: who is maintaining the result of this decision?

Current failure in "openSUSE:Tumbleweed": have choice for python > 3.0: python36 python38 python39

I think this has to be handled in the prjconf of the base prj.

Thanks for bringing that to my attention - it's kinda pecculiar that somebody would buildequire 'python > 3.0' - the package 'python' has always been '2.x' and python3 was for >= 3.0 But I can 'de-prefer' python36 and python39 for this case. Cheers, Dominique

On Thu, Aug 27, 2020 at 8:40 AM Ben Greiner wrote:

Hi,

Am 27.08.20 um 13:54 schrieb Dominique Leuenberger / DimStar:

...

On Thu, 2020-08-27 at 13:42 +0200, Olaf Hering wrote:

...

Am Fri, 17 Jul 2020 10:44:58 -0400 schrieb Neal Gompa :

...

We still have a concept of a *default* Python version and things will just *work* that way? Do we plan to have one? If yes: who is maintaining the result of this decision?

Current failure in "openSUSE:Tumbleweed": have choice for python > 3.0: python36 python38 python39

I think this has to be handled in the prjconf of the base prj. Thanks for bringing that to my attention - it's kinda pecculiar that somebody would buildequire 'python > 3.0' - the package 'python' has always been '2.x' and python3 was for >= 3.0

The python singlespec macros actually should take care of the distinction between python and python3 [1]. Now with possibly different Python3 existing in parallel this will actually make more sense.

No it doesn't. If I am building an application, I want it to use one and only one Python flavor, the default Python 3 flavor. Having parallel Python 3 versions is fine, as long as something is the default and the %python3_* and %py3_* macros will use that.

...

But I can 'de-prefer' python36 and python39 for this case.

Doesn't that contradict the idea of having coexisting python36, python38, etc.?

Note that the Leap repositories in devel:languages:python:* including "backports" are already broken in this regard for days and nobody seems to care [2].

Since devel:languages:python:* is maintained by the Python interpreter team too, I guess they decided breaking the backports was fine? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Aug 27, 2020 at 10:02 AM Tomas Chvatal wrote:

On Thu, 2020-08-27 at 08:44 -0400, Neal Gompa wrote:

...

...

...

Note that the Leap repositories in devel:languages:python:* including "backports" are already broken in this regard for days and nobody seems to care [2].

Since devel:languages:python:* is maintained by the Python interpreter team too, I guess they decided breaking the backports was fine?

Thanks for the friendly attitude.

The problem was an overlook of the new interpreters in the generator script.

Now it should be rebased [1]. It will just take quite time to recompile everything as we injected different interpreter by accident afterall.

It wasn't meant to be unfriendly. At some point, there will be irreconcilable differences between TW and Leap. And I already don't expect devel:languages:python:backports to remain consistently working since Python packaging is being rearchitected in TW. At some point, they're going to have to break. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org