[opensuse-python] Re: Python 3 packaging change (was: [opensuse-factory] Tumbleweed - Review of the week 2020/29)
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.
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].
Cheers, Dominique
Regards, Ben [1] https://en.opensuse.org/openSUSE:Packaging_Python#Requires.2C_Provides_and_s... [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1175777 -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
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-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
(Only replying on opensuse-python for this thread) Am 27.08.20 um 14:44 schrieb Neal Gompa:
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.
I disagree. If I am building an application or package A and use the default Python 3 flavor 3.X then it will be installed into python3.X/site-packages/A. If I want to use it with another application B with flavor 3.Y, that application won't find it in python3.Y/site-packages/A. That's what singlespec is for: Create packages for all possible flavors and only skip those which won't work. (using the skip_python* macro). My understanding is, that this mechanism is not ready yet for different Python 3 flavors, but that's the way it should go IMHO.
Since devel:languages:python:* is maintained by the Python interpreter team too, I guess they decided breaking the backports was fine?
I can hardly imagine they intended to break it *that* way. Ben -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
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. Tom [1] https://github.com/openSUSE/python-backports-generate/commit/82536dbe6422f9e...
On Thu, Aug 27, 2020 at 10:02 AM Tomas Chvatal
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-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Am 27.08.20 um 17:08 schrieb Neal Gompa:
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.
But doesn't backports specifically exist to cater for the differences? Otherwise one could just use Factory! There is a reason, why responsible maintainers use macro conditionals with %suse_version and the sorts. -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
participants (3)
-
Ben Greiner
-
Neal Gompa
-
Tomas Chvatal