All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Boccassi <luca.boccassi@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v4] python*-setuptools: add separate packages for pkg_resources module
Date: Sat, 25 May 2019 13:59:32 +0100	[thread overview]
Message-ID: <1558789172.5382.2.camel@gmail.com> (raw)
In-Reply-To: <CAMKF1so2vXwvoXhidY64+JcHUiyaQVhqdP3SrWmcNmoZEooWaA@mail.gmail.com>

On Fri, 2019-05-24 at 10:29 -0700, Khem Raj wrote:
> On Wed, May 22, 2019 at 3:58 AM Luca Boccassi <luca.boccassi@gmail.co
> m> wrote:
> > 
> > On Tue, 2019-05-21 at 19:06 -0700, Khem Raj wrote:
> > > On Tue, May 21, 2019 at 5:36 AM <
> > > luca.boccassi@gmail.com
> > > > wrote:
> > > > From: Luca Boccassi <
> > > > luca.boccassi@microsoft.com
> > > > > 
> > > > 
> > > > The pkg_resources Python module is useful by itself, for
> > > > example
> > > > for
> > > > automatic loading of resources shipped in a Python package.
> > > > Add separate packages for it, so that users can depend on them
> > > > individually and avoid pulling in the entire setuptools, which
> > > > include scripts to download other packages, which might not be
> > > > desired on minimal images.
> > > > 
> > > > Other distributions like Debian and Ubuntu already split
> > > > setuptools
> > > > and pkg-resources in this way.
> > > > 
> > > > The setuptools packages now depend on the new pkg-resources
> > > > packages,
> > > > to avoid regressions for other packages that depend on them
> > > > already.
> > > > 
> > > > Signed-off-by: Luca Boccassi <
> > > > luca.boccassi@microsoft.com
> > > > > 
> > > > 
> > > > ---
> > > > v2: restrict new RDEPENDS to class-target. As advised by
> > > > Alexander,
> > > > bitbake
> > > >     cannot resolve native rdeps that mention package names
> > > > rather
> > > > than
> > > >     recipe names.
> > > > v3: manually add RPROVIDES to the native class instead of
> > > > restricting the
> > > >     RDEPENDS to the target class as a better workaround. Also
> > > > document why
> > > >     the package is being split.
> > > > v4: re-send to the correct thread, no changes.
> > > > 
> > > >  meta/recipes-devtools/python/python-setuptools.inc | 11
> > > > +++++++++++
> > > >  1 file changed, 11 insertions(+)
> > > > 
> > > > diff --git a/meta/recipes-devtools/python/python-setuptools.inc
> > > > b/meta/recipes-devtools/python/python-setuptools.inc
> > > > index 357aa07086..f49e078697 100644
> > > > --- a/meta/recipes-devtools/python/python-setuptools.inc
> > > > +++ b/meta/recipes-devtools/python/python-setuptools.inc
> > > > @@ -37,3 +37,14 @@ do_install_prepend() {
> > > >  }
> > > > 
> > > >  BBCLASSEXTEND = "native nativesdk"
> > > > +
> > > > +# The pkg-resources module can be used by itself, without the
> > > > package downloader
> > > > +# and easy_install. Ship it in a separate package so that it
> > > > can
> > > > be used by
> > > > +# minimal distributions.
> > > > +PACKAGES =+ "${PYTHON_PN}-pkg-resources "
> > > > +FILES_${PYTHON_PN}-pkg-resources =
> > > > "${PYTHON_SITEPACKAGES_DIR}/pkg_resources/*"
> > > > +# Due to the way OE-Core implemented native recipes, the
> > > > native
> > > > class cannot
> > > > +# have a dependency on something that is not a recipe name.
> > > > Work
> > > > around that by
> > > > +# manually setting RPROVIDES.
> > > > +RDEPENDS_${PN}_append = " ${PYTHON_PN}-pkg-resources"
> > > > +RPROVIDES_append_class-native = " ${PYTHON_PN}-pkg-resources-
> > > > native"
> > > 
> > > do we need to handle nativesdk case ?
> > 
> > Hi,
> > 
> > The parsing step of "bitbake core-image-minimal -c populate_sdk"
> > works,
> > while without the append_class-native workaround it fails
> > immediately.
> > Is this enough or is there something else I should run to check?
> > 
> 
> yeah usually to test nativesdk we need to do it with generated SDK

I do have a nativesdk target in the distro at $work, but I realise it
might be different enough. Is there a simple config change/command to
generate it from Poky?

-- 
Kind regards,
Luca Boccassi


      reply	other threads:[~2019-05-25 12:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 21:09 [PATCH] python*-setuptools: add separate packages for pkg_resources module luca.boccassi
2019-05-20 14:14 ` Richard Purdie
2019-05-20 15:04   ` Luca Boccassi
2019-05-20 16:28     ` Alexander Kanavin
2019-05-21 10:59 ` [PATCH v2] " luca.boccassi
2019-05-21 11:11   ` richard.purdie
2019-05-21 12:36 ` [PATCH v4] " luca.boccassi
2019-05-22  2:06   ` Khem Raj
2019-05-22 10:58     ` Luca Boccassi
2019-05-24 17:29       ` Khem Raj
2019-05-25 12:59         ` Luca Boccassi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1558789172.5382.2.camel@gmail.com \
    --to=luca.boccassi@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.