[gentoo-dev] [RFC] EAPI

[gentoo-dev] [RFC] EAPI

[Kristian Benoit]

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.

Kristian

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] EAPI

[Brian Harring]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] EAPI

[Ciaran McCreesh]

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

On Fri, 26 Aug 2005 15:32:42 -0500 Brian Harring <ferringb@gentoo.org>
wrote:
| A) what does xml bring to the table explicitly that is needed?

A cool three letter acronym. Portage is currently lacking in this
department. How are we expected to sell it to enterprise users if it
doesn't use XML?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] EAPI

[Dan Meltzer]

Maybe I'm incorrect, but I believe Kristian was not saying use XML,
but using xml as a comparasison (I know there is a better word.. but
its escaping me... that comparassion thing on the SAT's).  He's not
saying to use xml, but in order to extend portage, extend it much like
xml extends html, with a pluggable script referenced as the dtd
equivvelent.

On 8/26/05, Kristian Benoit <kbenoit@opersys.com> 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.
> 
> Kristian
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] EAPI

[Drake Wyrm]

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

Brian Harring <ferringb@gentoo.org> wrote:
> On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
[snip]
> > 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
[snip]
> 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).

If I read the idea correctly, it's not suggesting that Portage implement
XML as a config engine; it's just using XML as an example. The analogy
works just as well for SGML DTDs or C libraries.

> B) EAPI is pretty much bash env template switching
[snip]

Perhaps the EAPI handling could be implemented using eclasses, rather
than something in the deep, dark, python-based internals.

-- 
That is not dead which can eternal lie,
And with strange eons even death may die.
	-- The Call of Cthulu, II. The Tale of Inspector Legrasse

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] EAPI

[Brian Harring]

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

On Fri, Aug 26, 2005 at 03:02:13PM -0700, Drake Wyrm wrote:
> Brian Harring <ferringb@gentoo.org> wrote:
> > B) EAPI is pretty much bash env template switching
> [snip]
> 
> Perhaps the EAPI handling could be implemented using eclasses, rather
> than something in the deep, dark, python-based internals.

Effectively the implementation is essentially an eclass, but won't 
wind up in $PORTDIR/eclass due to the fact it's also slightly bound to 
python side.
For example, the ebuild build operation class knows not to command the 
ebuild processor to execute the configure phase for eapi0, 'coz that 
hook doesn't exist.  For >eap0, it commands it.  That's about the 
extent of python side awareness at this point, beyond checking min/max 
eapi support.
~harring


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] EAPI

[Marius Mauch]

On 08/26/05  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.

As EAPI is closely tied to portage internals (DEPEND handling for
example) that's not really going to work from within the tree. Otherwise
we could just distribute portage completely with the tree, no? Don't
mind having it pluggable inside portage, but as it can potentially
affect many areas I doubt that's realistic.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list