Re: [gentoo-portage-dev] PATCH: initial EAPI awareness

[Paul de Vrieze]

On Wednesday 31 August 2005 14:57, Brian Harring wrote:
>
> First off, a modifier of an EAPI, say EAPI=3-strict isn't valid; why?
> strict is most likely a restriction, a specific negation of some
> aspect of eapi3.

No 3-strict would be a variant of version 3 in the way that 
html-4.0-strict and html-4.0-transitional are related. They are very 
similar versions, but for a computer just different as computers don't 
handle and shouldn't handle "a little bit different". As such a portage 
implementation would either support the api called "3-strict" or it 
wouldn't. This would be independent of it's support of some other api 
that was called "3". The same numbers would be for user aid only.

> Restrict is the place for it, or a similar metadata key.  Yes this
> doesn't hold across all cases (someone could've just decided 3-strict
> was a cool name fex), but throwing it out there to point out that eapi
> is ebuild templates, not restrictions.

EAPI is not templates. It is API. It specifies what format the 
ebuild/eclass has. Currently the planned versions are only implemented by 
small differences, but to portage the different api's should be 
completely separate. It just happens that a lot of code can and will be 
shared between the api implementations.

> Further, any deviation where loss of backwards compatibility would
> occur (limiting or extending bash syntax) is implicitly another
> format, thus beyond eapi's keen.  EAPI is ebuild (the format) spec/api
> *only*, see comments below re: format support for further explanation.

Why should this be beyond EAPI. As long as any portage in run can read the 
ebuild well enough to extract the EAPI value and decide that it doesn't 
recognize it, things should be transparent. Or do you propose that for 
future/experimental ebuild formats we introduce yet another variable 
"EFORMAT" to specify what format the ebuild has. For me it's kind of 
double to do that.

> Re: tagging EAPI at the top of a file, infra would probably shoot me
> for doing such- till a live, fully compatible and *roughly* equivalent
> parser is available, portage would have to do a bit of grepping,
> jacking up the regen times.

If in cache EAPI can be gotten from the cache. If not, I don't think it 
matters where in the file EAPI occurs from the standpoint of getting it's 
value. The only thing would be that in the future a fast EAPI parser 
could be made that would just look at EAPI and get its version. I could 
easilly write you such a parser.

> One thing I'm going to clarify also, is that the rewrite *does not*
> make it hard to tag new formats in.  There's no reason to jam
> everything into ebuilds, especially considering we are bound by
> existing definitions, and a body of 20,000 live ebuilds users/devs
> would get rather pissed off about if we forced a change across it.

What I want is a way to be able to in the future change the ebuild format 
to aleviate some of it's deficiencies. And this in such a way that all 
current ebuilds can still be used, and that is compatible with any 
reasonable portage version. (So format variations should wait for some 
time for older portages to get out of view).

> If it's not an adjustment, a tweak, an extension/subtraction of ebuild
> functionality, eapi isn't applicable imo, and a seperate format is the
> route to go (one that could easily live alongside in the tree).

You mean a different file extension. That could be possible, but for a 
proper forward compatible format this is not necessary. We now have the 
possibility to make the current ebuild format forward compatible. Why not 
do this immediately. The nice thing is that this forward compatibility is 
even compatible with current (and old) portage versions as long as no too 
big changes are made before the non-eapi-aware portage versions are 
phased out.

> EAPI is just for ebuild format.  alt formats (whether sh based or
> otherwise) would be wise to version their version also.

Why not combine them. I really don't see why we should have dual version 
systems.

> Either way, getting to the point of why strings suck badly in the
> point where it matters- as format version identifiers for the code
> that does the actual work.
>
> Example code for numeric, say we have eapi 0-5 at this point.
>
> def configure(self):
> 	if self.pkg.eapi > 0:
> 		...call configure phase...
> 	return
>
>
> example code for strings

This is broken as portage should not allow formats it doesn't know about.

>
> def configure(self):
> 	if self.pkg.eapi in ("0", "1", "2", "3", "4", "5"):
> 		...call configure phase...
> 	return
>
> This sucks.

What about this pseudocode:
API=self.pkg.eapi
if not isnumber(API):
    error "unsupported api or malformatted api"
else
    if asnumber(API) >= 0 and asnumber(API) <= 5:
        ...call configure phase...
    return


And as you should remember from programming 101 you should check for 
faulty inputs anyway.

>
> the response is "well, stick it into a list somewhere".  Can do, but
> you have to mangle each list everytime you add a new eapi.  That's a
> good way to lead to dumb ass bugs when tinkering with a new eapi
> level.

Support for the api should be added anyway. Along with the code to handle 
this new api it shouldn't be hard to have this code register itself in 
the list with handled api's.

> Suggestions regarding using enumerations still dodge that point that
> via strings, you're building a finite set of matching strings to
> execute a block of code under, rather then establishing a min/max
> during which an int eapi should execute a block of code.  Latter's a
> helluva lot simpler then the former.

there will anyway only be a finite fixed set of api's that any portage 
version should handle. If it does know about 4 and 5 but not about 4.5 it 
shouldn't handle 4.5.

> The arguement here is that it's somehow cleaner; it's not really.  You
> still have magic strings ("configure"), and a massive table of
> capabilities.  I used a single capability; if you're doing
> "has_capability" for every logic check, you're going to get into some
> very ugly terrain of magic const's all over the place.

The idea is that there is a class for every api version. Some classes 
share lot's of code with other classes and are siblings. Some are hardly 
alike. There then only needs to be one check and that calls the 
approprate class.

> If I want to work on the next extension of eapi, I create an ebuild
> that has the new incremented #, and I can *already* have that eapi up
> and running, usurping the previous eapi definition.  No forced
> manual redefinition of stuff that is an easy way to induce bugs
> (increased manual work == bugs).  I can start extending the previous
> definition, tweaking it to I want without having to gut half of the
> controlling code.

You mean subclassing the new eapi in the portage code, and registering it 
under the new name. That's just about or maybe even more easy than 
anything else.

> Yes, I'm talking about it from the code perspective, but remember that
> this is the area that ultimately *matters*; control of the ebuild env
> is via the python side of things.  Keeping that as bug free, and clean
> as possible is what matters from where I sit; we can extend the ebuild
> env/template without issue, but swiveling from template to template is
> totally controlled by python side portage, which means that bit of
> code best be clean and robust.

From my perspective the sh part of portage is even messier than the python 
part. From my perspective doing things at the python side is a lot 
better.

> That said, if you dig through my earlier patch, and comments about
> needing to handle int conversion better rather then flattening it to
> 0, the code *is* forwards compatible if someone decides to stick
> strings into EAPI.  In other words, it's a moot debate due to the fact
> that the internal representation of eapi (is it a string, or is it an
> int?) is specific to that portage version; whatever version supports an
> eapi with strings tagged into has the fun of addressing the issues I've
> brought up above.

If that is the case I don't care. I don't believe that strings are an 
issue, but I'm happy as long as when I stick EAPI="pauls_test_format" 
into my ebuild your portage bails out.

> So basically the debate over string vs int can be left to when someone
> tries to add a non int eapi; forewarning: I'll bring up these points
> again when it's raised.  It's a Bad Idea (tm), and there is a damn
> good reason you don't see it elsewhere when dealing with versions of
> something :)

I still argue that treating api versions as numbers is the bad idea (tm), 
and using ranges to check them even worse. Each version should be treated 
differently anyway so at that point the check needs to be done anyway. 
More than one check is ugly code.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net