Re: [gentoo-dev] [RFC] EAPI

[Brian Harring]

On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
> On the EAPI subject Brian just brought back, I had this idea that we
> could use the same approch XML took with HTML.
>
> The ebuild could define which EAPI to use, but instead beiing a version,
> the EAPI would be an ebuild API definition. The equivalent to the XML's
> dtd. The ebuild could point to a directory named
> $PORTDIR/eapi/<eapi-name>/ which would contain a python script named
> <eapi-name>.py. If not already loaded, that plugable eapi would be
> loaded before processing the ebuild.
>
> That way, there is no outdated ebuild format. There is just a default
> format which is the actual format.
>
> It could also be an XML defining the ebuild's build sequence and other
> particularities a group of ebuild could have.
Few questions; 
A) what does xml bring to the table explicitly that is needed?
   remember portage doesn't have a hard dep on xml parsing libs yet, 
   this would add it (livecd/stage* potentially needing adjustment as 
   a result).
B) EAPI is pretty much bash env template switching; xml/python plugins 
   don't help in that respect, although a python plugin for that eapi 
   level may be added at some point (right now it's not required for 
   the eapi v0/v1 python side components).

I am worried, long term mind you, in tracking the differences between 
eapi levels and keeping the code clean.  My thought for way down the 
line when an eapi level has long since gone unused is to break it out 
of portage and into it's own package as a plugin.
Specifics of it haven't yet gotten to, mainly because it's not worth 
sweating over till rewrite is usable (priorities), but that's the long 
term intention for EAPI.

Beyond that, the question of what needs to be tracked outside of 
python/bash code (what would be stuck in the suggested xml) should 
also be clarified, since I'm not seeing what all would be jammed in 
there.
~harring