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: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpZts2PYDbd3.pgp
Description: PGP signature
