[OE-core] [PATCH] python-setuptools.inc: avoid using += with an over-ride

Richard Purdie richard.purdie at linuxfoundation.org
Fri Jul 6 09:11:58 UTC 2018


On Thu, 2018-07-05 at 17:57 -0700, Andre McCurdy wrote:
> On Thu, Jul 5, 2018 at 5:07 PM, Burton, Ross <ross.burton at intel.com>
> wrote:
> > On 6 July 2018 at 00:39, Andre McCurdy <armccurdy at gmail.com> wrote:
> > > On Wed, Jul 4, 2018 at 5:53 AM, Burton, Ross <ross.burton at intel.c
> > > om> wrote:
> > > > On 4 July 2018 at 01:55, Andre McCurdy <armccurdy at gmail.com>
> > > > wrote:
> > > > >  DEPENDS += "${PYTHON_PN}"
> > > > > -DEPENDS_class-native += "${PYTHON_PN}-native"
> > > > > -DEPENDS_class-nativesdk += "nativesdk-${PYTHON_PN}"
> > > > > +DEPENDS_class-native = "${PYTHON_PN}-native"
> > > > > +DEPENDS_class-nativesdk = "nativesdk-${PYTHON_PN}"
> > > > 
> > > > Whilst there's nothing wrong with this patch, as the
> > > > BBCLASSEXTEND
> > > > handles DEPENDS-munging isn't this a better fix:
> > > > 
> > > >   DEPENDS += "${PYTHON_PN}"
> > > >  -DEPENDS_class-native += "${PYTHON_PN}-native"
> > > >  -DEPENDS_class-nativesdk += "nativesdk-${PYTHON_PN}"
> > > 
> > > Removing the over-rides completely results in both the native and
> > > nativesdk variants gaining a new dependency on
> > > python-distribute-native (courtesy of setuptools.bbclass).
> > 
> > setuptools.bbclass:DEPENDS += "python-distribute-native"
> > 
> > If python-distribute-native is a build dependency for target then
> > its a dependency for native and nativesdk too, right?
> 
> DEPENDS has been over-ridden for native and nativesdk for some time,
> so either the dependency gets provided indirectly or it's not
> required at all?

I'd suspect indirectly but hard to tell :/.


> > Considering python-distribute is just an alias for python-
> > setuptools
> > (its a RPROVIDES in the recipe, and the pip entry is just a
> > dependnecy) I guess the setuptools class should follow setuptools3
> > and
> > depend on python-setuptools-native instead of
> > python-distribute-native.
> > 
> > Context is this from 2015:
> > 
> > commit c4553e07cdbec5c29a74a43e0c5fdb2bb5583f7a
> > Author: Alejandro Hernandez <alejandro.hernandez at linux.intel.com>
> > Date:   Thu May 14 16:49:56 2015 +0000
> > 
> >     python3-distribute: Upgrade to python3-setuptools 15.2
> > 
> >     python3-distribute was merged back to python3-setuptools in
> > 2013,
> >     and it is no longer being maintained, this upgrade also
> > provides
> >     functionality that will be needed for python3-pip.
> > 
> > The same needs to be applied to the py2 classes, as both Py2 and
> > Py3
> > use the same version of setuptools.
> 
> That all sounds plausible, but starts to unravel into a bigger set of
> potential cleanups. For example, digging a little more uncovers this
> from distutils-base.bbclass:
> 
>   DEPENDS  += "${@["${PYTHON_PN}-native ${PYTHON_PN}",
> ""][(d.getVar('PACKAGES') == '')]}"
>   RDEPENDS_${PN} += "${@['', '${PYTHON_PN}-core']['${CLASSOVERRIDE}'
> == 'class-target']}"
> 
> The first line adding to DEPENDS for target and nativesdk (but not
> native) and the second line adding to RDEPENDS for target only.
> Should this be re-written to make use of over-rides?

I suspect class- overrides did not exist when that code was written.
Rewriting it using them would be a good cleanup.

> And looking at nativesdk builds in general, why does
> DISTRO_FEATURES_NATIVE contain ipv6 and xattr but
> DISTRO_FEATURES_NATIVESDK does not? I couldn't find any comments to
> explain that.

I suspect nativesdk should have those and its just a oversight.
Unfortunately we have a number of little details like this, I do take a
pass at some things when I have time but clearly there are things which
can be improved.

FWIW I tend to look at them from a risk perspective too and how well we
can know whether the cleanup will or won't risk breakage before
deciding where to make changes.

Cheers,

Richard





More information about the Openembedded-core mailing list