Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Kent Fredric <kentfredric@gmail.com>]

On 12 March 2012 15:20, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring <ferringb@gmail.com> wrote:
>> Pragmatic reality, the eapi function actually would work fine.  As
>> 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?  How do you know what to use to source it if you don't know the
> EAPI?  Right 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.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"