From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
by nuthatch.gentoo.org with esmtp (Exim 4.43)
id 1EASAs-0008GQ-7L
for garchives@archives.gentoo.org; Wed, 31 Aug 2005 12:58:43 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7VCtp3u014998;
Wed, 31 Aug 2005 12:55:51 GMT
Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30])
by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7VCtodH000802
for <gentoo-portage-dev@lists.gentoo.org>; Wed, 31 Aug 2005 12:55:50 GMT
Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler)
by smtp.gentoo.org with esmtpa (Exim 4.43)
id 1EASAH-00006k-JX
for gentoo-portage-dev@lists.gentoo.org; Wed, 31 Aug 2005 12:58:05 +0000
Date: Wed, 31 Aug 2005 07:57:44 -0500
From: Brian Harring <ferringb@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Message-ID: <20050831125744.GV13987@nightcrawler>
References: <20050827105357.GY1701@nightcrawler> <20050830151515.2c4df6f2@andy.genone.homeip.net> <20050830132846.GL13987@nightcrawler> <200508301648.02586.pauldv@gentoo.org> <20050830234611.GO13987@nightcrawler> <20050831125253.6e88c66d@andy.genone.homeip.net>
Precedence: bulk
List-Post: <mailto:gentoo-portage-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-portage-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-portage-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-portage-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-portage-dev.gentoo.org>
X-BeenThere: gentoo-portage-dev@gentoo.org
Reply-to: gentoo-portage-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="CMEQapY8OuP5ao1l"
Content-Disposition: inline
In-Reply-To: <20050831125253.6e88c66d@andy.genone.homeip.net>
User-Agent: Mutt/1.5.8i
X-Archives-Salt: a334f1a2-d88b-4d60-a3f6-94af583963d5
X-Archives-Hash: 10f5337fb3fefbf31e7fe4ae55b9d231
--CMEQapY8OuP5ao1l
Content-Type: text/plain; charset=utf8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hokay, this is pretty much my response to the string vs int stuff,=20
slammed into one email.
First clarifying the assumption I'm after a max test for eapi testing;=20
not the case- stated so already in this thread.
Restating it again, for stable, a check of if it's > 0 (with int=20
conversion failures being knocked up to 1 fex) is effectively the same=20
thing as if str(portage_const.EAPI) in ("", "0"). Stated also that=20
for rewrite, this approach won't work, and you're stuck specifying=20
either a range of supported EAPI (max *and* min), or specifying every=20
single individual eapi identifier, which I'll clarify before is going=20
to burn any maintainer of such code.
On Wed, Aug 31, 2005 at 12:52:53PM +0200, Marius Mauch wrote:
> On 08/30/05 Brian Harring wrote:
>=20
> > Why am I being so damned stubborn about numbers for this? Cause I=20
> > don't want users having to dink around with knowing that eapi=3D"really=
=20
> > cool version" somehow maps out to 3.1. Further, eapi version *likely*
> > will wind up as the slotting for any split out portage-ebuild package,
> > and slots traditionally have always been ints.
>=20
> Thanks for that last comment, it actually prooves our point ;)
> Yes, SLOTs are *generally* numeric strings, as they are generally tied
> to major versions. But as soon as more than the major part of the
> version is important ints don't work anymore (and never ever mention
> float again, version numbers aren't floats), and in some cases you find
> non-version data in SLOT (like $CTARGET).
Summation of string based failings.
First off, a modifier of an EAPI, say EAPI=3D3-strict isn't valid; why? =20
strict is most likely a restriction, a specific negation of some=20
aspect of eapi3.
=20
Restrict is the place for it, or a similar metadata key. Yes this=20
doesn't hold across all cases (someone could've just decided 3-strict=20
was a cool name fex), but throwing it out there to point out that eapi=20
is ebuild templates, not restrictions.
Further, any deviation where loss of backwards compatibility would=20
occur (limiting or extending bash syntax) is implicitly another=20
format, thus beyond eapi's keen. EAPI is ebuild (the format) spec/api=20
*only*, see comments below re: format support for further explanation.=20
Re: tagging EAPI at the top of a file, infra would probably shoot me=20
for doing such- till a live, fully compatible and *roughly* equivalent=20
parser is available, portage would have to do a bit of grepping,=20
jacking up the regen times.
One thing I'm going to clarify also, is that the rewrite *does not*=20
make it hard to tag new formats in. There's no reason to jam=20
everything into ebuilds, especially considering we are bound by=20
existing definitions, and a body of 20,000 live ebuilds users/devs=20
would get rather pissed off about if we forced a change across it.
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=20
route to go (one that could easily live alongside in the tree).
EAPI is just for ebuild format. alt formats (whether sh based or=20
otherwise) would be wise to version their version also.
Either way, getting to the point of why strings suck badly in the=20
point where it matters- as format version identifiers for the code=20
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
def configure(self):
if self.pkg.eapi in ("0", "1", "2", "3", "4", "5"):
...call configure phase...
return
This sucks.
the response is "well, stick it into a list somewhere". Can do, but=20
you have to mangle each list everytime you add a new eapi. That's a=20
good way to lead to dumb ass bugs when tinkering with a new eapi=20
level.
or... capabilities, as suggested.
capabilities =3D {"0":["configure"],
"1":["configure"],
"2":["configure"],
"3":["configure"],
"4":["configure"],
"5":["configure"],}
=09
def has_capability(eapi, capability):
try: return capability in capabilities[eapi]:
except KeyError: return False
def configure(self):
if has_capability(self.pkg.eapi, "configure"):
...call configure phase...
return
or (slightly nastier example)
# eapi5 being eapi4, just with bash side changes. implicit is that=20
# their is bash side changes between each eapi, just stating it=20
# explicitly to avoid the 'wtf'=20
capabilities =3D {"0":["configure"],
"1":["configure", "test_src_uri"],
"2":["configure", "test_src_uri"],
"3":["configure", "test_src_uri", "full_depriving"],
"4":["configure", "test_src_uri", "full_depriving", "user_management"],
"5":["configure", "test_src_uri", "full_depriving", "user_management"],}
def configure(self):
if "configure" in capabilities.get(eapi, []):
...call configure phase...
return
Suggestions regarding using enumerations still dodge that point that=20
via strings, you're building a finite set of matching strings to=20
execute a block of code under, rather then establishing a min/max=20
during which an int eapi should execute a block of code. Latter's a=20
helluva lot simpler then the former.
The arguement here is that it's somehow cleaner; it's not really. You=20
still have magic strings ("configure"), and a massive table of=20
capabilities. I used a single capability; if you're doing=20
"has_capability" for every logic check, you're going to get into some=20
very ugly terrain of magic const's all over the place.
Further, if attempting to map out what has changed between each eapi=20
version, it's the wrong place to do so; that's implementation right=20
there, specifically python side knowledge of how to support that=20
version.
Proper design would actually use a magic constant at the top of the=20
file, CONFIGURE_REQUIRED =3D 1 or something of the sort.
If I want to work on the next extension of eapi, I create an ebuild=20
that has the new incremented #, and I can *already* have that eapi up=20
and running, usurping the previous eapi definition. No forced=20
manual redefinition of stuff that is an easy way to induce bugs=20
(increased manual work =3D=3D bugs). I can start extending the previous=20
definition, tweaking it to I want without having to gut half of the=20
controlling code.
Yes, I'm talking about it from the code perspective, but remember that=20
this is the area that ultimately *matters*; control of the ebuild env=20
is via the python side of things. Keeping that as bug free, and clean=20
as possible is what matters from where I sit; we can extend the ebuild=20
env/template without issue, but swiveling from template to template is=20
totally controlled by python side portage, which means that bit of=20
code best be clean and robust.
That said, if you dig through my earlier patch, and comments about=20
needing to handle int conversion better rather then flattening it to=20
0, the code *is* forwards compatible if someone decides to stick strings=20
into EAPI. In other words, it's a moot debate due to the fact that=20
the internal representation of eapi (is it a string, or is it an int?)=20
is specific to that portage version; whatever version supports an eapi=20
with strings tagged into has the fun of addressing the issues I've=20
brought up above.
So basically the debate over string vs int can be left to when someone=20
tries to add a non int eapi; forewarning: I'll bring up these points=20
again when it's raised. It's a Bad Idea (tm), and there is a damn=20
good reason you don't see it elsewhere when dealing with versions of=20
something :)
Final comment on this; there's a reason pkgs are release with=20
major/minor as numeric; detection of capabilities, handling=20
capabilities is *much* cleaner via such an approach.
~harring
--CMEQapY8OuP5ao1l
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDFalIvdBxRoA3VU0RAk73AKClO2/jnth/HABg3/TQyX24s9abWgCgq2ir
Y/WZDX4x3LT2RgABDZ/ijtU=
=P50x
-----END PGP SIGNATURE-----
--CMEQapY8OuP5ao1l--
--
gentoo-portage-dev@gentoo.org mailing list