On Fri, Mar 4, 2022 at 6:06 AM Konrad Weihmann <[email protected]> wrote: > > > > On 04.03.22 14:13, Ross Burton wrote: > > On Fri, 4 Mar 2022 at 12:44, Konrad Weihmann <[email protected]> wrote: > >> For me that would be a candidate to be added to meta-python, or are > >> there any core recipes that currently break because of the new behavior? > > > > This is restoring existing behaviour, so I believe it should be in > > core. There's going to be enough recipes using this that it is > > justified in core. I expect we'll have deleted this by the time the > > next LTS comes around too. > > > >> Furthermore the variables names are the same, so if people accidentally > >> (or due to complex injection trees/classes/distro settings/whatever have > >> new setuptools3 and this class here in the same recipe, things become > >> rather unpredictable - as of now there are the same but surely they will > >> start to diverge at one point. > > > > That's intentional: if you have a recipe which needs the legacy > > behaviour, just change the import from setuptool3 to > > setuptools3_legacy. > > Can you name any publicly available recipe that requires that? > > For me this is the same situation as with the python2 > python3 > transition - there wasn't any fallback provided in core, but outside of > core it was - so I would propose to do the same here. > > If that legacy class will be part of core it's likely that it will > remain till EOL of kirkstone which is somewhat in ~2025 (by current > planning) - and meta-python2 showed that even then some recipes still > haven't migrated (yes, chromium looking at you).
latest chromium does not need py2 in OE context anymore for a year or so now. > All in all I think core should just provide *one* way to do it while the > legacy cases can easily live outside in a separate layer (meta-python > for instance as the "old" distutils have been put there as well). > There are recipes in meta-oe and meta-python which would need this and both layer only list core as sole dependency, if we put it in either of these layers, then one will depend on other which is not nice, so I rather would prefer it in core. , regarding distutils classes we did move them to meta-python but there are recipes in meta-oe needing them e.g. unattended-upgrades which now are forced to be moved to meta-python which is less than ideal but can be lived with. seuptool-legacy is similar to autotools-brokensep in spirit. python2 issue was of a different nature > In additional everyone was worried so much about reputation lately that > doing this long announced transition, while keeping the "old" way > enabled (and creating more maintenance effort in the end), would > definitely send the wrong signal to the community. > > > > >> While we are at it pypi class needs a fallback too, because for me this > >> is the standard way of packaging python recipes and new class points to > >> the new setuptools implementation - so if we want to have this here, we > >> might need a fallback for pypi class as well > > > > My understanding is that almost anything on pypi is already a pure > > Python module and is mostly unaffected by the changes. > > > > Ross > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162742): https://lists.openembedded.org/g/openembedded-core/message/162742 Mute This Topic: https://lists.openembedded.org/mt/89547022/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
