From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S6z6W-000499-IE for garchives@archives.gentoo.org; Mon, 12 Mar 2012 06:51:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DE13E09A8; Mon, 12 Mar 2012 06:51:24 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 669D7E0971 for ; Mon, 12 Mar 2012 06:50:44 +0000 (UTC) Received: by iaoo28 with SMTP id o28so7704653iao.40 for ; Sun, 11 Mar 2012 23:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=T/cGEkxK3ydOcgItrldicvDSd24IRF3cFqeudvt7Kns=; b=nc0/A8es7E4K0PpGDhBkgltYa18OP549cMMbmyGJxJGpN83DI9vZdT8doM6r2qrAIb 65n+tVCffpkPnpadFhwu+AepT78djSsLKW1Nng7vbstCdt2hpWZaaM22OB1rfFYqP/Q5 qBzoGtnfcedDAnv0EUoC1NfaZAj+JkcttBdW7jvLJUNtSgwnl5hCCTfjvPTd0BtYWuze sRHoHx4d//RhFJoox21p1ZdrgaqMQ9Gs/QDXLlZ+WiZ1cad1P07WUtsXXAaDPE3yHTU3 j3G+Ais5Itpax4oeCzgIPQnYyHVBHci8qroR+Uj99ter0T3otFAch6nJ9XqKsdBI7kxJ fb/A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.42.144.201 with SMTP id c9mr15001683icv.29.1331535043913; Sun, 11 Mar 2012 23:50:43 -0700 (PDT) Received: by 10.42.96.8 with HTTP; Sun, 11 Mar 2012 23:50:43 -0700 (PDT) In-Reply-To: References: <4F58FC55.7070005@orlitzky.com> <20120308184820.108fc30c@googlemail.com> <4F592612.6050203@orlitzky.com> <20120309060424.09cdce1e@pomiocik.lan> <4F599692.9050503@orlitzky.com> <20120309172921.281ee5a0@pomiocik.lan> <4F5A368D.2020605@orlitzky.com> <20314.14772.897891.110368@a1i15.kph.uni-mainz.de> <4F5A3E6C.4040900@orlitzky.com> <4F5A4246.8080605@gentoo.org> <20120312020344.GE7579@localhost> Date: Mon, 12 Mar 2012 19:50:43 +1300 Message-ID: Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 3ba40f7f-3bcd-42fe-982f-94d1c89f8ce6 X-Archives-Hash: 48a38f6550f47499ce38f7733625b0db On 12 March 2012 15:20, Rich Freeman wrote: > On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrot= e: >> Pragmatic reality, the eapi function actually would work fine. =C2=A0As >> pointed out elsewhere, bash parses as it goes- which isn't going to >> change. > > Unless the ebuild isn't written in bash... > > How do you source the ebuild if you don't know what to use to source > it? =C2=A0How do you know what to use to source it if you don't know the > EAPI? =C2=A0Right now all the existing EAPIs use bash, but there is no > reason the file couldn't be xml, or python, or just about anything > else. A convention that is often used in this scenario is to combine a hashbang call with that specific sourcer stripping that hashbang prior to the parse. ie: foo.ebuild: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process "eapi-xml-5" ( as defined by the current $PATH setting ) This process can easily then strip the #! stanza before sending the content to an XML parser. ( ps. while I wouldn't actually use XML, its a good example case because standard shell-script style commenting is illegal syntax in XML ) The benefits of this approach seem obvious, but there are also obvious downsides. 1. PRO: Unlike /usr/bin/eapi , this style is PMS Agnostic, and only requires the PMS have a process named "eapi-xml-5" *somewhere* in the system under $PATH 2. CON: Unlike /usr/bin/eapi , you're limited by what you can send it , /usr/bin/env eapi xml-5 would be preferable syntax imo, but it doesn't work, because its parsed as [ '/usr/bin/env' , 'eapi xml-5' ] which then yeilds a "permission denied" due to no command with that name existing. 3. PRO: There's not /much/ risk of a user trying to run it directly, mostly because there's no +x bit 4. CON: This syntax is going to conflict with whatever language we are proceeding, which while this caveat is dealt with by the command that the file is dispatched to, its a lot of work getting everything else to play ball ( editors won't understand, linters wont understand, various other tools that work strictly with the native forms of that language wont understand ) and this problem exists for *every* case where the coding system we're targeting doesn't natively support whatever "magic" indicators we're trying to stuff in the file. 5. PRO: detecting this notation being used in a file is cheap-ish , you only have to read 2 characters into the file to know its using this notation. As a result of all these, it seems to me if we ever want to support non-bash or non-scripting sources ( ie: YAML, JSON, XML , etc ) or any other language which doesn't support "# is a comment" , we're going to be pretty much forced to declare the EAPI outside the file somehow. Whether this is via the filename ( yes, I've seen that debate ) or via some other metadata file ( which seems more poison than cure ) would be the real issue. Having to store this in a metadata file that maps *.ebuild to EAPI would seem like a solution that would only increase the filesize of portage, and slow down runtime substantially, unless of course you had a per-repository index that sped this up and was generated during the metadata/ generation phase. Then $PMS could just load that file from each repository , and assuming the cache was still valid, it could easily know the EAPI for any .ebuild it would source in advance. --=20 Kent perl -e=C2=A0 "print substr( \"edrgmaM=C2=A0 SPA NOcomil.ic\\@tfrken\", \$_= * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"