Bug 241442 – [Future EAPI] Add a function like default for calling the eclass exported default function

• Product: Gentoo Hosted Projects
• Status: RESOLVED WONTFIX

[Description Petteri Räty (RETIRED) 2008-10-11 20:51:58 UTC]

23:49 < Betelgeuse> zmedico: default calls the Portage implementation right? Is there a way to call the one exported by eclasses?
23:49 < zmedico> what's up?
23:49 < zmedico> you have to know the eclass name
23:49 < zmedico> so you can call $ECLASS_phase
23:49 < Betelgeuse> Yeah but I would not having to
23:50 < zmedico> can add that in the next EAPI :)

So I propose we add eclass_default in the next EAPI.

[Comment 1 Ciaran McCreesh 2008-10-11 20:57:44 UTC]

I don't get it. Which eclass's function would it call?

[Comment 2 Petteri Räty (RETIRED) 2008-10-12 00:27:58 UTC]

(In reply to comment #1)
> I don't get it. Which eclass's function would it call?
> 

The one that would get used if the eclass did not define one.

[Comment 3 Petteri Räty (RETIRED) 2008-10-12 00:29:22 UTC]

(In reply to comment #2)
> (In reply to comment #1)
> > I don't get it. Which eclass's function would it call?
> > 
> 
> The one that would get used if the eclass did not define one.
> 

s/eclass/ebuild/

Basically if I inherit a b c and all of them export src_compile I want to be able to call c_src_compile in the src_compile of my ebuild by not having to know which one of the eclasses was the one exporting it.

[Comment 4 Michał Górny 2011-09-14 19:25:35 UTC]

I'd rather name it like 'next' and do a nice inheritance chain. It would be great if it could support three cases:

1) ebuilds calling their inherited eclasses:

inherit cmake-utils

src_install() {
	cmake-utils_src_install
	doinitd foo
}

where 'cmake-utils_src_install' would be replaced by simply 'next'.

2) eclasses calling their inherited eclasses;

3) (optionally) eclasses 'prepending' phases:

git-2_src_unpack() {
	...

	next # e.g. to default or another VCS
}

Of course, that would have to take a few assumptions:

1) ordering eclasses by inheritance -- every re-inherited eclass (along with its inherited eclasses) is moved to the end of inheritance chain, so we're clear which phases should go; and we don't want to call the same phase func twice in a 'next' chain,

2) possibly 'next' should localize its iterations so it can be called multiple times.

[Comment 5 SpanKY 2011-09-14 19:33:30 UTC]

let's avoid obtuse names when they aren't necessary.  "eclass_next" is much more clear and doesn't impose any more overhead.

[Comment 6 Ulrich Müller 2021-08-31 13:45:08 UTC]

What problem would this solve, actually? At the moment, ebuilds do this:

    inherit foo bar

    src_install() {
        bar_src_install
        <do some other things>
    }

and with the change they would do:

    inherit foo bar

    src_install() {
        eclass_default   # or next or eclass_next
        <do some other things>
    }

In the first example the reader immediately sees what function is called, while in the second example he must look up eclass order in the inherit line. Plus, if someone would reorder eclasses there, it would have the side effect that another function is called, in spite of the ebuild having an explicit phase function. Seems to me that this is more error prone.

In any case, no progress since 10 years. Closing.