[opensuse-python] python-importlib-metadata and backports
Hi, It looks like pypi modules that are obsolete with python 3.8 have been dropped from Factory, examples are importlib-metadata (and maybe also cursive). importlib-metadata has a pretty drastic impact on anything older than factory/python 3.8, as it is a dependency of many modules. We now have over 1000 unresolvables on any released distribution, which breaks quite a lot, including community work that is now entirely blocked because we managed to break older distros completely (again). I am wondering what the intentions here are, and whether we could come to a solution that does have less drastic impact on users of the python stack. we could a) patch the backports repo to have a :only_backports build path that includes those dropped packages again b) readd libraries that don't hurt but are necessary for older distros again to factory (my understanding is that factory-first also means that we are consolidating efforts in factory) c) fix more than 1000 upstream libraries to no longer use importlib-metadata Any preference? TIA, Dirk-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
Hi Dirk, We already released imporlib-metadata on Leap and SLE products. So it should be resolvable everywhere. If it is not then something is amiss but we processed the importlib-* stuff together with the pytest updates. HTH Tom Dirk Müller píše v Po 27. 04. 2020 v 09:44 +0200:
Hi,
It looks like pypi modules that are obsolete with python 3.8 have been dropped from Factory, examples are importlib-metadata (and maybe also cursive). importlib-metadata has a pretty drastic impact on anything older than factory/python 3.8, as it is a dependency of many modules.
We now have over 1000 unresolvables on any released distribution, which breaks quite a lot, including community work that is now entirely blocked because we managed to break older distros completely (again).
I am wondering what the intentions here are, and whether we could come to a solution that does have less drastic impact on users of the python stack.
we could
a) patch the backports repo to have a :only_backports build path that includes those dropped packages again
b) readd libraries that don't hurt but are necessary for older distros again to factory (my understanding is that factory-first also means that we are consolidating efforts in factory)
c) fix more than 1000 upstream libraries to no longer use importlib- metadata
Any preference?
TIA, Dirk-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
But you are right, it seem not to propagate :/ I would recommend asking maint-coord team whats going on. For some reason released but not visible SLE15 https://smelt.suse.de/incident/14582/ Still pending SLE12 https://smelt.suse.de/incident/14581/ Tom Tomas Chvatal píše v Po 27. 04. 2020 v 08:07 +0000:
Hi Dirk,
We already released imporlib-metadata on Leap and SLE products.
So it should be resolvable everywhere. If it is not then something is amiss but we processed the importlib-* stuff together with the pytest updates.
HTH
Tom
Dirk Müller píše v Po 27. 04. 2020 v 09:44 +0200:
Hi,
It looks like pypi modules that are obsolete with python 3.8 have been dropped from Factory, examples are importlib-metadata (and maybe also cursive). importlib-metadata has a pretty drastic impact on anything older than factory/python 3.8, as it is a dependency of many modules.
We now have over 1000 unresolvables on any released distribution, which breaks quite a lot, including community work that is now entirely blocked because we managed to break older distros completely (again).
I am wondering what the intentions here are, and whether we could come to a solution that does have less drastic impact on users of the python stack.
we could
a) patch the backports repo to have a :only_backports build path that includes those dropped packages again
b) readd libraries that don't hurt but are necessary for older distros again to factory (my understanding is that factory-first also means that we are consolidating efforts in factory)
c) fix more than 1000 upstream libraries to no longer use importlib- metadata
Any preference?
TIA, Dirk-- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
��칻 �&�zf���^�ˬz������{.n�+������Ǩ��r��i�m��0��ޙ������� �+a���w��� ��� ��
Hi Tomas,
But you are right, it seem not to propagate :/
I would recommend asking maint-coord team whats going on.
Well, the maintenance team released it only for SLE_15_SP1, not for SLE_15, not for SP2, not for Leap (and it is being removed from leap 15.2 because of factory dropping it) so the problem is only on non-maintained distributions.. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org
On 4/27/20 5:16 AM, Dirk Müller wrote:
Hi Tomas,
But you are right, it seem not to propagate :/
I would recommend asking maint-coord team whats going on.
Well, the maintenance team released it only for SLE_15_SP1, not for SLE_15, not for SP2, not for Leap (and it is being removed from leap 15.2 because of factory dropping it)
so the problem is only on non-maintained distributions..
Well, that very much depends on the definition of "non-maintained", SLE_15 because of ESPOS is in at least semi-maintained state until the end of 2022. The current system of breaking stuff for the sake of chasing the tip certainly creates a lot of extra work for many people, we should think about his some more. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
Robert Schweikert píše v Po 27. 04. 2020 v 07:16 -0400:
On 4/27/20 5:16 AM, Dirk Müller wrote:
Hi Tomas,
But you are right, it seem not to propagate :/ I would recommend asking maint-coord team whats going on.
Well, the maintenance team released it only for SLE_15_SP1, not for SLE_15, not for SP2, not for Leap (and it is being removed from leap 15.2 because of factory dropping it)
so the problem is only on non-maintained distributions..
Well, that very much depends on the definition of "non-maintained", SLE_15 because of ESPOS is in at least semi-maintained state until the end of 2022.
The current system of breaking stuff for the sake of chasing the tip certainly creates a lot of extra work for many people, we should think about his some more.
You need latest python code stack in LTSS supported codestream? We are supposed to do only minimal and security changes there anyway... Note that we prepared it on 15SP1 because the pytest was forked there otherwise we would prepare the stack on 15GA, like we prepared it for the SLE12 on SP3+. Afaik the backports generator reads whitelist and you can simply add more packages to the dlpy:backports and put them into whitelist and maintain them as long as you wish/need (if I am wrong the script can be extended for that too). Tom
On 4/27/20 7:38 AM, Tomas Chvatal wrote:
Robert Schweikert píše v Po 27. 04. 2020 v 07:16 -0400:
On 4/27/20 5:16 AM, Dirk Müller wrote:
Hi Tomas,
But you are right, it seem not to propagate :/ I would recommend asking maint-coord team whats going on.
Well, the maintenance team released it only for SLE_15_SP1, not for SLE_15, not for SP2, not for Leap (and it is being removed from leap 15.2 because of factory dropping it)
so the problem is only on non-maintained distributions..
Well, that very much depends on the definition of "non-maintained", SLE_15 because of ESPOS is in at least semi-maintained state until the end of 2022.
The current system of breaking stuff for the sake of chasing the tip certainly creates a lot of extra work for many people, we should think about his some more.
You need latest python code stack in LTSS supported codestream?
Not the whole stack, but we have a reasonably large number of Python packages that get maintained in OBS and then on a more or less regular basis we copy/import these packages verbatim into SLE (SLE 15 and SLE 12). So if builds get broken we have to do extra work to figure out what builds where and what extra steps we might have to take.
We are supposed to do only minimal and security changes there anyway...
Different modules have different policies. The idea that whatever is in the common code base only gets minimal and basically backport fixes has long gone out the window.
Note that we prepared it on 15SP1 because the pytest was forked there otherwise we would prepare the stack on 15GA, like we prepared it for the SLE12 on SP3+.
Afaik the backports generator reads whitelist and you can simply add more packages to the dlpy:backports and put them into whitelist and maintain them as long as you wish/need (if I am wrong the script can be extended for that too).
Tom �{.n�+����������� �+a���˛���m�)z{.��+�: �{Zr�az�'z��j)h���ǩ��h��0�����Ǩ�
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
participants (3)
-
Dirk Müller -
Robert Schweikert -
Tomas Chvatal