Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 179800

Summary: [Future EAPI] Add support for eclass functions that are always called
Product: Gentoo Hosted Projects Reporter: Petteri Räty (RETIRED) <betelgeuse>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: RESOLVED WONTFIX    
Severity: normal CC: esigra, haubi, slyfox
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 174380    

Description Petteri Räty (RETIRED) gentoo-dev 2007-05-25 20:11:31 UTC
Currently eclass functions are only called once and the last eclass in inherit is preferred. For for example Java eclasses java-pkg-2_pkg_setup setup will always need to be called or else the ebuild will fail when it needs VM switching. For this reason I propose a similar scheme to EXPORT_FUNCTIONS but those functions would always be called even if the ebuild providers implementations for them.

3:06 <@vapier> Betelgeuse: said functionality would be nice ... "ALWAYS_CALL" is a crappy name though :p
Comment 1 Ciaran McCreesh 2007-05-25 20:13:19 UTC
Why is this necessary? Why not just ensure that ebuilds use eclasses the way said eclasses are supposed to be used?
Comment 2 Petteri Räty (RETIRED) gentoo-dev 2007-05-25 20:59:54 UTC
(In reply to comment #1)
> Why is this necessary? Why not just ensure that ebuilds use eclasses the way
> said eclasses are supposed to be used?
> 

People make mistakes.
Comment 3 Ciaran McCreesh 2007-05-25 21:04:15 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Why is this necessary? Why not just ensure that ebuilds use eclasses the way
> > said eclasses are supposed to be used?
> 
> People make mistakes.

Sure, which is why we do testing. The problem with this approach is that when looking at a function defined in an ebuild, it's entirely unobvious that that function will do other things.
Comment 4 Petteri Räty (RETIRED) gentoo-dev 2007-05-25 21:11:59 UTC
(In reply to comment #3)
> 
> Sure, which is why we do testing. The problem with this approach is that when
> looking at a function defined in an ebuild, it's entirely unobvious that that
> function will do other things.
> 

It's not really easy to know what's going on now either when you inherit multiple eclasses without investing all the eclasses on what they export.
Comment 5 Ciaran McCreesh 2007-05-25 21:23:09 UTC
The point is, currently when you look at a function, it does what that function says unless that function is overridden. This is consistent with well established language design principles. What you're proposing is completely at odds with this -- no longer will a function be implemented in a single place. Rather, it will be a horrible mishmash of code from arbitrary locations similar to the widely criticised AOP paradigm. It's well known that 'goto' is harmful, but this is worse -- it's a 'comefrom'.

If the only use case for this is catching developer screwups, a better solution would be allowing eclasses to specify contract-style requirements. This would allow a larger category of mistakes to be caught, and doesn't have the associated ick factor.
Comment 6 Petteri Räty (RETIRED) gentoo-dev 2007-08-17 19:30:22 UTC
(In reply to comment #5)
> The point is, currently when you look at a function, it does what that function
> says unless that function is overridden. This is consistent with well
> established language design principles. What you're proposing is completely at
> odds with this -- no longer will a function be implemented in a single place.
> Rather, it will be a horrible mishmash of code from arbitrary locations similar
> to the widely criticised AOP paradigm. It's well known that 'goto' is harmful,
> but this is worse -- it's a 'comefrom'.
> 

Well what I want could also be implemented as phases that can never be defined in ebuilds which should fit your statement above. It would basically be like making the hooks java eclasses used official and only usable in eclasses. 
Comment 7 Michael Haubenwallner gentoo-dev 2009-07-17 14:46:21 UTC
The same mechanism could work to stack hooks found in multiple profile.bashrc.
Comment 8 Zac Medico gentoo-dev 2011-02-20 09:53:24 UTC
The interface could look something like this:

   add_phase_hook before pkg_setup $ECLASS_pre_pkg_setup

Portage has related register_die_hook and register_success_hook functions that might also be useful as EAPI additions.
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-08-30 10:51:14 UTC
To be honest, I don't really like the concept of introducing something that does something with no ability of disabling or overriding it. And if we make it possible, we kinda get back to square one, just the other way around.

For your use case, what if java is optional? Assuming that normally you'd do:

  use java && java-pkg-2_pkg_setup

With your proposed solution it will no longer be possible.

If you really want this, you have to have a stronger use case.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-09-06 21:34:26 UTC
Unlikely to get done right, no reply to basic issues for over a year. Closing as WONTFIX.
Comment 11 Zac Medico gentoo-dev 2015-10-28 21:30:58 UTC
(In reply to Michał Górny from comment #9)
> To be honest, I don't really like the concept of introducing something that
> does something with no ability of disabling or overriding it.

Maybe something like python's "super" would be more appropriate. That way, when you implement a phase function, you get to decide whether or not you want to call super.