>>>>> 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.
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
