Gentoo Archives: gentoo-portage-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Date: Wed, 31 Aug 2005 15:44:46
In Reply to: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness by Brian Harring
1 On Wednesday 31 August 2005 14:57, Brian Harring wrote:
2 >
3 > First off, a modifier of an EAPI, say EAPI=3-strict isn't valid; why?
4 > strict is most likely a restriction, a specific negation of some
5 > aspect of eapi3.
7 No 3-strict would be a variant of version 3 in the way that
8 html-4.0-strict and html-4.0-transitional are related. They are very
9 similar versions, but for a computer just different as computers don't
10 handle and shouldn't handle "a little bit different". As such a portage
11 implementation would either support the api called "3-strict" or it
12 wouldn't. This would be independent of it's support of some other api
13 that was called "3". The same numbers would be for user aid only.
15 > Restrict is the place for it, or a similar metadata key. Yes this
16 > doesn't hold across all cases (someone could've just decided 3-strict
17 > was a cool name fex), but throwing it out there to point out that eapi
18 > is ebuild templates, not restrictions.
20 EAPI is not templates. It is API. It specifies what format the
21 ebuild/eclass has. Currently the planned versions are only implemented by
22 small differences, but to portage the different api's should be
23 completely separate. It just happens that a lot of code can and will be
24 shared between the api implementations.
26 > Further, any deviation where loss of backwards compatibility would
27 > occur (limiting or extending bash syntax) is implicitly another
28 > format, thus beyond eapi's keen. EAPI is ebuild (the format) spec/api
29 > *only*, see comments below re: format support for further explanation.
31 Why should this be beyond EAPI. As long as any portage in run can read the
32 ebuild well enough to extract the EAPI value and decide that it doesn't
33 recognize it, things should be transparent. Or do you propose that for
34 future/experimental ebuild formats we introduce yet another variable
35 "EFORMAT" to specify what format the ebuild has. For me it's kind of
36 double to do that.
38 > Re: tagging EAPI at the top of a file, infra would probably shoot me
39 > for doing such- till a live, fully compatible and *roughly* equivalent
40 > parser is available, portage would have to do a bit of grepping,
41 > jacking up the regen times.
43 If in cache EAPI can be gotten from the cache. If not, I don't think it
44 matters where in the file EAPI occurs from the standpoint of getting it's
45 value. The only thing would be that in the future a fast EAPI parser
46 could be made that would just look at EAPI and get its version. I could
47 easilly write you such a parser.
49 > One thing I'm going to clarify also, is that the rewrite *does not*
50 > make it hard to tag new formats in. There's no reason to jam
51 > everything into ebuilds, especially considering we are bound by
52 > existing definitions, and a body of 20,000 live ebuilds users/devs
53 > would get rather pissed off about if we forced a change across it.
55 What I want is a way to be able to in the future change the ebuild format
56 to aleviate some of it's deficiencies. And this in such a way that all
57 current ebuilds can still be used, and that is compatible with any
58 reasonable portage version. (So format variations should wait for some
59 time for older portages to get out of view).
61 > If it's not an adjustment, a tweak, an extension/subtraction of ebuild
62 > functionality, eapi isn't applicable imo, and a seperate format is the
63 > route to go (one that could easily live alongside in the tree).
65 You mean a different file extension. That could be possible, but for a
66 proper forward compatible format this is not necessary. We now have the
67 possibility to make the current ebuild format forward compatible. Why not
68 do this immediately. The nice thing is that this forward compatibility is
69 even compatible with current (and old) portage versions as long as no too
70 big changes are made before the non-eapi-aware portage versions are
71 phased out.
73 > EAPI is just for ebuild format. alt formats (whether sh based or
74 > otherwise) would be wise to version their version also.
76 Why not combine them. I really don't see why we should have dual version
77 systems.
79 > Either way, getting to the point of why strings suck badly in the
80 > point where it matters- as format version identifiers for the code
81 > that does the actual work.
82 >
83 > Example code for numeric, say we have eapi 0-5 at this point.
84 >
85 > def configure(self):
86 > if self.pkg.eapi > 0:
87 > configure phase...
88 > return
89 >
90 >
91 > example code for strings
93 This is broken as portage should not allow formats it doesn't know about.
95 >
96 > def configure(self):
97 > if self.pkg.eapi in ("0", "1", "2", "3", "4", "5"):
98 > configure phase...
99 > return
100 >
101 > This sucks.
103 What about this pseudocode:
104 API=self.pkg.eapi
105 if not isnumber(API):
106 error "unsupported api or malformatted api"
107 else
108 if asnumber(API) >= 0 and asnumber(API) <= 5:
109 configure phase...
110 return
113 And as you should remember from programming 101 you should check for
114 faulty inputs anyway.
116 >
117 > the response is "well, stick it into a list somewhere". Can do, but
118 > you have to mangle each list everytime you add a new eapi. That's a
119 > good way to lead to dumb ass bugs when tinkering with a new eapi
120 > level.
122 Support for the api should be added anyway. Along with the code to handle
123 this new api it shouldn't be hard to have this code register itself in
124 the list with handled api's.
126 > Suggestions regarding using enumerations still dodge that point that
127 > via strings, you're building a finite set of matching strings to
128 > execute a block of code under, rather then establishing a min/max
129 > during which an int eapi should execute a block of code. Latter's a
130 > helluva lot simpler then the former.
132 there will anyway only be a finite fixed set of api's that any portage
133 version should handle. If it does know about 4 and 5 but not about 4.5 it
134 shouldn't handle 4.5.
136 > The arguement here is that it's somehow cleaner; it's not really. You
137 > still have magic strings ("configure"), and a massive table of
138 > capabilities. I used a single capability; if you're doing
139 > "has_capability" for every logic check, you're going to get into some
140 > very ugly terrain of magic const's all over the place.
142 The idea is that there is a class for every api version. Some classes
143 share lot's of code with other classes and are siblings. Some are hardly
144 alike. There then only needs to be one check and that calls the
145 approprate class.
147 > If I want to work on the next extension of eapi, I create an ebuild
148 > that has the new incremented #, and I can *already* have that eapi up
149 > and running, usurping the previous eapi definition. No forced
150 > manual redefinition of stuff that is an easy way to induce bugs
151 > (increased manual work == bugs). I can start extending the previous
152 > definition, tweaking it to I want without having to gut half of the
153 > controlling code.
155 You mean subclassing the new eapi in the portage code, and registering it
156 under the new name. That's just about or maybe even more easy than
157 anything else.
159 > Yes, I'm talking about it from the code perspective, but remember that
160 > this is the area that ultimately *matters*; control of the ebuild env
161 > is via the python side of things. Keeping that as bug free, and clean
162 > as possible is what matters from where I sit; we can extend the ebuild
163 > env/template without issue, but swiveling from template to template is
164 > totally controlled by python side portage, which means that bit of
165 > code best be clean and robust.
167 From my perspective the sh part of portage is even messier than the python
168 part. From my perspective doing things at the python side is a lot
169 better.
171 > That said, if you dig through my earlier patch, and comments about
172 > needing to handle int conversion better rather then flattening it to
173 > 0, the code *is* forwards compatible if someone decides to stick
174 > strings into EAPI. In other words, it's a moot debate due to the fact
175 > that the internal representation of eapi (is it a string, or is it an
176 > int?) is specific to that portage version; whatever version supports an
177 > eapi with strings tagged into has the fun of addressing the issues I've
178 > brought up above.
180 If that is the case I don't care. I don't believe that strings are an
181 issue, but I'm happy as long as when I stick EAPI="pauls_test_format"
182 into my ebuild your portage bails out.
184 > So basically the debate over string vs int can be left to when someone
185 > tries to add a non int eapi; forewarning: I'll bring up these points
186 > again when it's raised. It's a Bad Idea (tm), and there is a damn
187 > good reason you don't see it elsewhere when dealing with versions of
188 > something :)
190 I still argue that treating api versions as numbers is the bad idea (tm),
191 and using ranges to check them even worse. Each version should be treated
192 differently anyway so at that point the check needs to be done anyway.
193 More than one check is ugly code.
195 Paul
197 --
198 Paul de Vrieze
199 Gentoo Developer
200 Mail: pauldv@g.o
201 Homepage:


Subject Author
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness Zac Medico <zmedico@×××××.com>