On Wed, Mar 7, 2012 at 11:27 PM, Ulrich Mueller <u...@gentoo.org> wrote:
>>>>>> On Wed, 7 Mar 2012, Alec Warner wrote:
>
>>> *** Proposal 1: "Parse the EAPI assignment statement" ***
>>> [...]
>
>> I don't like this idea because the sane way should be easy and
>> straightforward. Mixing a constant declaration with bash assignment
>> just confuses users who think the assignment is full bash when in
>> fact it is not.
>
>> EAPI=$(somefunc)
>> EAPI=${SOMEVAR%%-*}
>> and so forth all don't meet the regex (and would be flagged
>> invalid.) However a naive author might think they work.
>
> Such constructs also cannot be used with any of the other proposed
> solutions. And in fact, nobody is using such things in practice.
> _All_ ebuilds in the Portage tree can be successfully parsed with the
> regexp proposed.I'm not saying they are valid EAPI syntax; but they are all valid bash. I tend to assume all authors are as...ignorant as myself. Lets not give them the rope to hang themselves. > > The obvious sanity check, i.e. comparing the EAPI obtained by parsing > and by sourcing, could be added to repoman, which would prevent such > non-conforming ebuilds from being committed to the tree. > >>> *** Proposal 2: "EAPI in header comment" *** >>> [...] > >> Overloading is bad. > >> There is no real difference between: >> #!/usr/bin/ebuild --eapi 5 >> # EAPI=5 > >> The problem is that the former is also the way to specify how to >> execute the ebuild; so unless you plan to make ebuilds executable and >> having /usr/bin/ebuild provide the ebuild environment, using that >> syntax is confusing to users. > > I agree with this point. > > Many file formats are identifying themselves with a magic token (as > it is used by sys-apps/file), but it is not necessarily a shebang. > > Ulrich >
