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

[Rich Freeman]

On Sun, Aug 17, 2014 at 2:54 AM, Ulrich Mueller <ulm@g.o> wrote:
>>>>>> On Sat, 16 Aug 2014, William Hubbs wrote:
>
>> 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.
>
> I'm strongly opposed against this proposal, too. Our current system
> essentially works. Also, already now you can suppress automatic
> calling of phase functions at the eclass level (by not exporting them)
> and at the ebuild level (by defining explicit phase functions).
>

Honestly, I'm not sure that the status quo a great solution.  I think
we're much better off if eclasses are designed with the need to call
them explicitly kept in mind.

Rather than one big phase override that does 5 things, they should
have 5 separate calls to do each of those things in turn, and perhaps
one convenience function that calls all 5 in sequence.

Then if you want to use two eclasses that each expect to do 5 things
in the same phase you have a hope of being able to call them in a way
that makes sense, and not have things break anytime either of the
eclasses change.

Sure, you CAN work around many of these issues today, but the current
practice encourages eclass developers to build their eclasses with the
assumption that they are the only eclass around, and to avoid
educating their consumers about the need to call functions, little
documentation, etc.  The thinking is that there is no need for the foo
eclass maintainers to warn developers about the need to trigger their
new phase function, because it will happen automatically.  The problem
is that some percentage of the time, this won't actually happen.  It
is just infrequent enough that we tolerate it.

Thinking about it a bit more, the one case where the status quo might
be helpful is for eclasses that aren't general-consumption.  For
example, there are a million kde packages in the tree, and if it makes
sense to have each of those just set a few variables in the package
and inherit phase functions from a master kde eclass that makes
maintenance far simpler.  This tends not to cause problems because all
the ebuilds that use the eclass are maintained by the same project and
are closely related (and I don't think it is a good idea to use this
behavior for a kde eclass that anything that links to libkde is
intended to use - just for packages that are part of kde-meta and so
on).

Unfortunately, with our current design we can't exclude inheritance
for some eclasses and not others.  Possible options to get around this
include having different types of eclasses controlled by some setting
in the eclass file, something other than eclasses like meta-ebuilds
which can be inherited by other ebuilds perhaps with some kind of
namespace isolation (like private classes in most programming
languages), and two different inherit statements that behave
differently (which is basically the same as two kinds of eclasses, but
it gives control to the ebuild maintainers instead of the eclass
maintainers so that when things change there is a different kind of
pain).

Ok, I realize I'm thinking out loud here so I'll just leave it at
that.  I'm open to arguments - I just don't think the current state is
as clean as it could be so we really should consider any reasonable
proposals for change.

Rich