[gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Hello,

As some of you may have noticed, lately introduced 'double include
preventions' have caused changes in effective phase functions in a few
ebuilds. Also, often it is undesirable that change in inherits of
an eclass may cause an undesired change of exported functions. To solve
these problems, we are proposing the following:


1. If an ebuild does not provide an explicit phase function, the phase
functions *directly exported* by *directly inherited* eclasses are used
to find a suitable default,

2. Thus, if an eclass inherits another eclass and expects the phase
functions of that eclass to be effective to the ebuild, it needs to
create its own phase function and export it.


This should make the ebuild behavior simpler to understand and saner.
It should also fix the forementioned issues, and allow us to make
the 'source eclasses only once'[1] proposal simpler.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=422533

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Zac Medico]

On 08/14/2012 02:44 AM, Michał Górny wrote:
> Hello,
> 
> As some of you may have noticed, lately introduced 'double include
> preventions' have caused changes in effective phase functions in a few
> ebuilds.

Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
the ifndef block? The function implementations themselves can be inside
the ifndef block, since that only need to be sourced once.

> Also, often it is undesirable that change in inherits of
> an eclass may cause an undesired change of exported functions. To solve
> these problems, we are proposing the following:
> 
> 
> 1. If an ebuild does not provide an explicit phase function, the phase
> functions *directly exported* by *directly inherited* eclasses are used
> to find a suitable default,
> 
> 2. Thus, if an eclass inherits another eclass and expects the phase
> functions of that eclass to be effective to the ebuild, it needs to
> create its own phase function and export it.
> 
> 
> This should make the ebuild behavior simpler to understand and saner.
> It should also fix the forementioned issues, and allow us to make
> the 'source eclasses only once'[1] proposal simpler.
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533

I'm not sure that your cure isn't worse than the disease.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Tue, 14 Aug 2012 12:46:30 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/14/2012 02:44 AM, Michał Górny wrote:
> > Hello,
> > 
> > As some of you may have noticed, lately introduced 'double include
> > preventions' have caused changes in effective phase functions in a
> > few ebuilds.
> 
> Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
> the ifndef block? The function implementations themselves can be
> inside the ifndef block, since that only need to be sourced once.

Isn't that an awful kind of undefined behavior? We're already
on a slippery ground assuming that sourced data changes between
inherits. Assuming EXPORT_FUNCS will work some other ugly way is even
worse.

> > Also, often it is undesirable that change in inherits of
> > an eclass may cause an undesired change of exported functions. To
> > solve these problems, we are proposing the following:
> > 
> > 
> > 1. If an ebuild does not provide an explicit phase function, the
> > phase functions *directly exported* by *directly inherited*
> > eclasses are used to find a suitable default,
> > 
> > 2. Thus, if an eclass inherits another eclass and expects the phase
> > functions of that eclass to be effective to the ebuild, it needs to
> > create its own phase function and export it.
> > 
> > 
> > This should make the ebuild behavior simpler to understand and
> > saner. It should also fix the forementioned issues, and allow us to
> > make the 'source eclasses only once'[1] proposal simpler.
> > 
> > [1]:https://bugs.gentoo.org/show_bug.cgi?id=422533
> 
> I'm not sure that your cure isn't worse than the disease.

In any case, 2. should happen even now. Eclasses should be simple
and predictable, and debugging random failures isn't something nice.
Unless you're saying that adding phase functions overrides to
work-around failures which you don't even understand is a good solution.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 909 bytes --]

On Tuesday 14 August 2012 16:39:57 Michał Górny wrote:
> On Tue, 14 Aug 2012 12:46:30 -0700 Zac Medico wrote:
> > On 08/14/2012 02:44 AM, Michał Górny wrote:
> > > As some of you may have noticed, lately introduced 'double include
> > > preventions' have caused changes in effective phase functions in a
> > > few ebuilds.
> > 
> > Can't that be avoided by putting the EXPORT_FUNCTIONS call outside of
> > the ifndef block? The function implementations themselves can be
> > inside the ifndef block, since that only need to be sourced once.
> 
> Isn't that an awful kind of undefined behavior? We're already
> on a slippery ground assuming that sourced data changes between
> inherits. Assuming EXPORT_FUNCS will work some other ugly way is even
> worse.

the "other way" is "the way EXPORT_FUNCS has always worked", so it's not like 
it's anything new for people to wrassl' with
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Tue, 14 Aug 2012 11:44:49 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> As some of you may have noticed, lately introduced 'double include
> preventions' have caused changes in effective phase functions in a few
> ebuilds. Also, often it is undesirable that change in inherits of
> an eclass may cause an undesired change of exported functions.

The problem here is that eclasses aren't clearly split between "utility"
and "does stuff", so people are inheriting "does stuff" eclasses to
get utilities. The fix is to stop having stupidly huge complicated
eclasses; changing inherit behaviour is just wallpapering over the
gaping hole.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Tue, 14 Aug 2012 21:45:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 14 Aug 2012 11:44:49 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > As some of you may have noticed, lately introduced 'double include
> > preventions' have caused changes in effective phase functions in a
> > few ebuilds. Also, often it is undesirable that change in inherits
> > of an eclass may cause an undesired change of exported functions.
> 
> The problem here is that eclasses aren't clearly split between
> "utility" and "does stuff", so people are inheriting "does stuff"
> eclasses to get utilities. The fix is to stop having stupidly huge
> complicated eclasses; changing inherit behaviour is just wallpapering
> over the gaping hole.

Soo, how do you propose to handle bug 422533 without changing inherit
behavior?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Tue, 14 Aug 2012 22:54:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 14 Aug 2012 11:44:49 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > As some of you may have noticed, lately introduced 'double include
> > > preventions' have caused changes in effective phase functions in a
> > > few ebuilds. Also, often it is undesirable that change in inherits
> > > of an eclass may cause an undesired change of exported functions.
> > 
> > The problem here is that eclasses aren't clearly split between
> > "utility" and "does stuff", so people are inheriting "does stuff"
> > eclasses to get utilities. The fix is to stop having stupidly huge
> > complicated eclasses; changing inherit behaviour is just
> > wallpapering over the gaping hole.
> 
> Soo, how do you propose to handle bug 422533 without changing inherit
> behavior?

We can't change inherit behaviour in EAPI 5 anyway since it's a global
scope function, so I was planning to ignore it and hope that by the time
EAPI 6 comes along, people will have learned not to write huge eclasses
that do more than one thing.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[hasufell]

On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
> 
> We can't change inherit behaviour in EAPI 5 anyway since it's a
> global scope function, so I was planning to ignore it and hope that
> by the time EAPI 6 comes along, people will have learned not to
> write huge eclasses that do more than one thing.
> 

great idea, let's wait 5 years then

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Tue, 14 Aug 2012 23:01:05 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 08/14/2012 10:56 PM, Ciaran McCreesh wrote:
> > 
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time EAPI 6 comes along, people will have learned not to
> > write huge eclasses that do more than one thing.
> 
> great idea, let's wait 5 years then

Sorry, but the Council voted down the "you can have it immediately"
approach because people got upset about file extensions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

On Tue, 14 Aug 2012 21:56:38 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 14 Aug 2012 22:54:13 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 14 Aug 2012 11:44:49 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > As some of you may have noticed, lately introduced 'double
> > > > include preventions' have caused changes in effective phase
> > > > functions in a few ebuilds. Also, often it is undesirable that
> > > > change in inherits of an eclass may cause an undesired change
> > > > of exported functions.
> > > 
> > > The problem here is that eclasses aren't clearly split between
> > > "utility" and "does stuff", so people are inheriting "does stuff"
> > > eclasses to get utilities. The fix is to stop having stupidly huge
> > > complicated eclasses; changing inherit behaviour is just
> > > wallpapering over the gaping hole.
> > 
> > Soo, how do you propose to handle bug 422533 without changing
> > inherit behavior?
> 
> We can't change inherit behaviour in EAPI 5 anyway since it's a global
> scope function, so I was planning to ignore it and hope that by the
> time EAPI 6 comes along, people will have learned not to write huge
> eclasses that do more than one thing.

And why? I believe we have quite a clean rule that *EAPI goes before
inherit*.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Tue, 14 Aug 2012 23:09:55 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > We can't change inherit behaviour in EAPI 5 anyway since it's a
> > global scope function, so I was planning to ignore it and hope that
> > by the time EAPI 6 comes along, people will have learned not to
> > write huge eclasses that do more than one thing.
> 
> And why? I believe we have quite a clean rule that *EAPI goes before
> inherit*.

That rule will only start applying from EAPI 6 onwards.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Zac Medico]

On 08/14/2012 01:54 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 21:45:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
>> On Tue, 14 Aug 2012 11:44:49 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>>> As some of you may have noticed, lately introduced 'double include
>>> preventions' have caused changes in effective phase functions in a
>>> few ebuilds. Also, often it is undesirable that change in inherits
>>> of an eclass may cause an undesired change of exported functions.
>>
>> The problem here is that eclasses aren't clearly split between
>> "utility" and "does stuff", so people are inheriting "does stuff"
>> eclasses to get utilities. The fix is to stop having stupidly huge
>> complicated eclasses; changing inherit behaviour is just wallpapering
>> over the gaping hole.

Ciaran's assessment sounds pretty accurate to me.

> Soo, how do you propose to handle bug 422533 without changing inherit
> behavior?

Close it as WONTFIX. The ifndef thing that we're doing now seems like a
reasonable approach.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Tue, 14 Aug 2012 14:09:17 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> On 08/14/2012 01:54 PM, Michał Górny wrote:
> > On Tue, 14 Aug 2012 21:45:56 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > 
> >> On Tue, 14 Aug 2012 11:44:49 +0200
> >> Michał Górny <mgorny@gentoo.org> wrote:
> >>> As some of you may have noticed, lately introduced 'double include
> >>> preventions' have caused changes in effective phase functions in a
> >>> few ebuilds. Also, often it is undesirable that change in inherits
> >>> of an eclass may cause an undesired change of exported functions.
> >>
> >> The problem here is that eclasses aren't clearly split between
> >> "utility" and "does stuff", so people are inheriting "does stuff"
> >> eclasses to get utilities. The fix is to stop having stupidly huge
> >> complicated eclasses; changing inherit behaviour is just
> >> wallpapering over the gaping hole.
> 
> Ciaran's assessment sounds pretty accurate to me.
> 
> > Soo, how do you propose to handle bug 422533 without changing
> > inherit behavior?
> 
> Close it as WONTFIX. The ifndef thing that we're doing now seems like
> a reasonable approach.

But you're aware that this 'reasonable approach' just made the whole
problem by changing exported functions, right?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

On Tue, 14 Aug 2012 23:51:17 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?

No, what made the whole problem is awful eclasses that do far too many
things.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Zac Medico]

On 08/14/2012 02:51 PM, Michał Górny wrote:
> On Tue, 14 Aug 2012 14:09:17 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 08/14/2012 01:54 PM, Michał Górny wrote:
>>> On Tue, 14 Aug 2012 21:45:56 +0100
>>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>>>
>>>> On Tue, 14 Aug 2012 11:44:49 +0200
>>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>>> As some of you may have noticed, lately introduced 'double include
>>>>> preventions' have caused changes in effective phase functions in a
>>>>> few ebuilds. Also, often it is undesirable that change in inherits
>>>>> of an eclass may cause an undesired change of exported functions.
>>>>
>>>> The problem here is that eclasses aren't clearly split between
>>>> "utility" and "does stuff", so people are inheriting "does stuff"
>>>> eclasses to get utilities. The fix is to stop having stupidly huge
>>>> complicated eclasses; changing inherit behaviour is just
>>>> wallpapering over the gaping hole.
>>
>> Ciaran's assessment sounds pretty accurate to me.
>>
>>> Soo, how do you propose to handle bug 422533 without changing
>>> inherit behavior?
>>
>> Close it as WONTFIX. The ifndef thing that we're doing now seems like
>> a reasonable approach.
> 
> But you're aware that this 'reasonable approach' just made the whole
> problem by changing exported functions, right?

That just means that somebody made a mistake. They should have put the
EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
about the correct place to put the EXPORT_FUNCTIONS call, and that
problem is solved.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: [Future EAPI] Exporting phase funcs from direct inherits only

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 310 bytes --]

On Tuesday 14 August 2012 17:59:40 Zac Medico wrote:
> That just means that somebody made a mistake. They should have put the
> EXPORT_FUNCTIONS call *outside* of the ifndef block. Just educate people
> about the correct place to put the EXPORT_FUNCTIONS call, and that
> problem is solved.

sounds fine
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]