[OE-core] "inherit setuptools" versus "inherit pypi" -- a python style question
Robert P. J. Day
rpjday at crashcourse.ca
Thu Mar 2 11:23:52 UTC 2017
possibly a "best practices" question ... regarding recipe for
"python-psutil" (although this applies for numerous python recipes),
wind river linux 8 has a recipe for python-psutil_2.2.1.bb which
inherits pypi:
RDEPENDS_${PN} += " \
python-subprocess \
"
inherit pypi
a newer recipe i ran across in-house that someone else set up,
python-psutil_3.2.1.bb, instead inherits setuptools and gets the
source from github:
inherit setuptools
# 3.2.1 tag
SRCREV = "99f6abf9bcff3abff815b8e93c8cd2fbe26487a2"
SRC_URI = "git://github.com/giampaolo/psutil.git;protocol=https"
S = "${WORKDIR}/git"
RDEPENDS_${PN} += " \
python-subprocess \
"
finally, the current (meta-openembedded) meta-python recipe,
python-psutil_5.0.1.bb, inherits both:
inherit pypi setuptools
require python-psutil.inc
and the corresponding .inc file contains:
RDEPENDS_${PN} += " \
${PYTHON_PN}-shell \
${PYTHON_PN}-subprocess \
${PYTHON_PN}-threading \
"
so the first recipe inherits pypi, the second one inherits setuptools,
and the third inherits *both*. what is the *preferred* style?
i'm assuming that if a python module is availably via pypi, then
you'd go with that; otherwise, just use regular setuptools. and not
being a python guru, why does that third recipe need to inherit both?
i did a quick grep of the current meta-python layer to see the
frequency of each, and got:
$ grep -r "inherit pypi$" | wc -l
13
$
$ grep -r "inherit pypi setuptools" | wc -l
157
$
so, clearly, far more python recipes inherit both as opposed to just
inheriting pypi. i don't know enough about python recipes to
appreciate if this distinction is necessary or not. can someone
clarify this? thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
More information about the Openembedded-core
mailing list