Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[gentoo-dev] [PATCH 2/2] Example use of edefault.

5 views
Skip to first unread message

Michał Górny

unread,
May 1, 2013, 4:50:03 PM5/1/13
to
---
gx86/dev-python/setuptools/setuptools-0.6.33.ebuild | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild b/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
index 4f4f3aa..91a8d57 100644
--- a/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
+++ b/gx86/dev-python/setuptools/setuptools-0.6.33.ebuild
@@ -37,7 +37,7 @@ python_prepare_all() {
# Disable tests requiring network connection.
rm -f setuptools/tests/test_packageindex.py

- distutils-r1_python_prepare_all
+ edefault
}

python_test() {
@@ -48,5 +48,5 @@ python_test() {
python_install() {
DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT="1" \
DONT_PATCH_SETUPTOOLS="1" \
- distutils-r1_python_install
+ edefault
}
--
1.8.2.1

Michał Górny

unread,
May 1, 2013, 4:50:03 PM5/1/13
to
Hi, everyone.

This one goes to gentoo-dev since it's a potentially wider idea
and I'd like to get other developers opinion on.

As you most likely already know, distutils-r1 allows ebuilds to define
sub-phase functions like:

python_compile() {
# commands which will be run for each impl
do_something_magical
}

Often, ebuilds do not want to override the sub-phases completely
but instead call the default implementation:

python_install_all() {
use doc && local HTML_DOCS=( doc/html/. )
distutils-r1_python_install_all
}

So the behavior is quite similar to the regular phase functions.
However, the function names ended up quite verbose.

To make this more friendly, I would likely to locally introduce
'edefault' function in the eclass (name can change). The function would
-- similarly to 'default' in regular phase functions -- call
the default code for the sub-phase.

For example, the above would change to:

python_install_all() {
use doc && local HTML_DOCS=( doc/html/. )
edefault
}

I will send in reply a patch adding the described magic to the eclass,
and a second one showing how an example ebuild can be changed
(dev-python/setuptools).

What are your thoughts?

--
Best regards,
Michał Górny
signature.asc

Michał Górny

unread,
May 1, 2013, 4:50:03 PM5/1/13
to
---
gx86/eclass/distutils-r1.eclass | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 47b5b97..4c2e819 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -206,6 +206,20 @@ fi
# }
# @CODE

+# @FUNCTION: edefault
+# @USAGE: [<args>...]
+# @DESCRIPTION:
+# Runs the default distutils-r1 sub-phase implementation for the current
+# sub-phase. Available only in distutils-r1 sub-phases.
+#
+# Example:
+# @CODE
+# python_install_all() {
+# use doc && local HTML_DOCS=( doc/html/. )
+# edefault # == distutils-r1_python_install_all
+# }
+# @CODE
+
# @FUNCTION: esetup.py
# @USAGE: [<args>...]
# @DESCRIPTION:
@@ -515,8 +529,12 @@ distutils-r1_run_phase() {

mkdir -p "${TMPDIR}" || die

+ eval "edefault() { ${1} }"
+
"${@}"

+ unset -f edefault
+
if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
then
popd >/dev/null || die
--
1.8.2.1

Michał Górny

unread,
May 11, 2013, 5:40:02 AM5/11/13
to
Fixed naming the proper default sub-phase and declaring 'edefault'
in python_prepare_all().
---
gx86/eclass/distutils-r1.eclass | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 47b5b97..e5c2a3a 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -206,6 +206,20 @@ fi
# }
# @CODE

+# @FUNCTION: edefault
+# @USAGE: [<args>...]
+# @DESCRIPTION:
+# Runs the default distutils-r1 sub-phase implementation for the current
+# sub-phase. Available only in distutils-r1 sub-phases.
+#
+# Example:
+# @CODE
+# python_install_all() {
+# use doc && local HTML_DOCS=( doc/html/. )
+# edefault # == distutils-r1_python_install_all
+# }
+# @CODE
+
# @FUNCTION: esetup.py
# @USAGE: [<args>...]
# @DESCRIPTION:
@@ -515,8 +529,12 @@ distutils-r1_run_phase() {

mkdir -p "${TMPDIR}" || die

+ eval "edefault() { distutils-r1_${1}; }"
+
"${@}"

+ unset -f edefault
+
if [[ ${DISTUTILS_IN_SOURCE_BUILD} && ! ${DISTUTILS_SINGLE_IMPL} ]]
then
popd >/dev/null || die
@@ -579,7 +597,11 @@ distutils-r1_src_prepare() {

# common preparations
if declare -f python_prepare_all >/dev/null; then
+ eval "edefault() { distutils-r1_python_prepare_all; }"
+
python_prepare_all
+
+ unset -f edefault
else
distutils-r1_python_prepare_all
fi
--
1.8.2.1

Mike Gilbert

unread,
May 11, 2013, 12:00:02 PM5/11/13
to
On Sat, May 11, 2013 at 5:30 AM, Michał Górny <mgo...@gentoo.org> wrote:
> Fixed naming the proper default sub-phase and declaring 'edefault'
> in python_prepare_all().
> ---

I think I prefer to explicitly name the function I want to call, so I
don't really see any great benefit here. I'm not strongly opposed to
it, but I don't see myself using it either.

Also, how would this interact with other eclasses which may define a
similar "edefault" function? Packages using distutils-r1 don't often
utilize other phase-happy eclasses, but I'm sure it will happen
eventually.

Michał Górny

unread,
May 11, 2013, 12:40:02 PM5/11/13
to
Well, the idea is that 'edefault' is defined by the eclass inventing
the particular sub-phase. So if sub-phase A calls sub-phase B
indirectly (trough the eclass and so on), edefault points to B
eventually.

Other thing would be, that after returning to A edefault will be no
longer defined. That's fixable though, if ever needed.
signature.asc

Ralph Sennhauser

unread,
May 11, 2013, 12:50:01 PM5/11/13
to
On Sat, 11 May 2013 11:51:39 -0400
Mike Gilbert <flo...@gentoo.org> wrote:

> On Sat, May 11, 2013 at 5:30 AM, Michał Górny <mgo...@gentoo.org>
> wrote:
> > Fixed naming the proper default sub-phase and declaring 'edefault'
> > in python_prepare_all().
> > ---
>
> I think I prefer to explicitly name the function I want to call, so I
> don't really see any great benefit here. I'm not strongly opposed to
> it, but I don't see myself using it either.

Same here for the reason you mention below. Long term I expect it to be
more of a hassle than typing a few additional letters now.

Michał Górny

unread,
May 15, 2013, 3:10:03 PM5/15/13
to
On Wed, 1 May 2013 22:42:05 +0200
Michał Górny <mgo...@gentoo.org> wrote:

> To make this more friendly, I would likely to locally introduce
> 'edefault' function in the eclass (name can change). The function would
> -- similarly to 'default' in regular phase functions -- call
> the default code for the sub-phase.

I've decided to withdraw the patch due to no interest from devs
in the feature. If anyone feels like it would be useful, we can get
back to it later.
signature.asc
0 new messages