Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Kent Fredric]

On 17 August 2014 09:54, William Hubbs <williamh@g.o> wrote:

> I strongly oppose this change, because I feel it will make our
> entire tree very unpredictable at best. I realize this might eliminate
> boilerplating from our tree. Weighing that against the possible
> ramifications in this big of a change in automagic behaviour, I think
> the cost is much higher than the gain.
>
>

I agree on that part, for what its worth.

The current system we have in place is an analogue of "role based" or
"trait based" inheritance, where you have very straight forward composition
behavior with regards to the final ebuild.

One of the parent classes "wins", and if you don't like this, you have to
adapt it manually.

This in practice usually proves more useful than diamond style multiple
inheritance, that while seeming like a nice idea in concept, in practice
proves more complicated than its worth.

The only downside I see is we don't have a clear straight forward collision
strategy, which is essential for most role based systems:

For instance,

  dog.eclass : function bark
  tree.eclass: function bark

Proves not to be resolvable automatically in a sensible way.

Collison systems I've seen usually do one of two things:

- In the event of a collision, demand the consumer resolve the problem by
redefining the function the collision occurs on in terms of its composite
parts. ( which is basically what we already do )
- Declare syntax to "exclude" a potential collision from either composite
part.

Our only real difference at present is unlike these systems, we assume we
can simply guess which one wins and just choose it automatically, where
collision systems tend to force you to deal with the situation if any
collision occurs.



> I am also not very comfortable with our current state, because it has
> a lot of uncertainty in terms of how the eclass phase functions are
> called.
>
> My counter proposal to this is that we stop calling eclass phase
> functions automatically, and to minimize the amount of boilerplating
>   we would have to do, we use a variable, such as ECLASS_PHASES  which
>   would be defined at the ebuild level and contain a list of the eclass
>   phase functions we want to run automatically.
>
> Going back to my previous example, say your ebuild does the following:
>
> -- code begins here --
>
> inherit foo bar
>
> # Foo and bar both have src_unpack and src_install functions.
> # we want foo's src_unpack and bar's src_install:
>
> ECLASS_PHASES="foo_src_unpack
>         bar_src_install"
>
> -- code ends here ---
>
> If ECLASS_PHASES is undefined, I think the default should be to not run
> the eclass phase functions.
>
> Yes, this means there is some boilerplating. However, there are some
> strong advantages:
>
> - this is no longer dependent on order of inheritance.
> - The ebuild author knows exactly which eclass phase functions will
>   be run.
>
>
This proposal, seems reasonable, given my comments. I anticipate however
its biggest downside would be
the requirement to state *all* the functions you want, which would lead to
maintenance headaches
due to people forgetting to declare they wanted some function or other.

So if you could sculpt it to be broader by default and have less scope for
developer error, that'd be an improvement.

--- code start --
ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
inherit foo bar baz


--- code end ---

here, src_unpack would be baz_src_unpack *regardless* of composition order
because "foo" and "bar" were barred from being used, and baz took
precedence as a result.

If baz provides no src_unpack, then the ebuild in question is simply left
without one.

You'll still need to declare src_unpack explicitly if you need use
conditional behaviour, however.
-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL