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

[Steven J Long <slong@rathaus.eclipse.co.uk>]

Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that 
a regex is not required during the scan, and nor is restricting it to the 
first N lines, though the latter may be desirable and could trivially 
exclude comment and whitespace-only or empty lines.

Ciaran McCreesh wrote:
>Michael Orlitzky wrote:
>> Fair enough, but aren't you arguing the opposite point with Zac? If
>> ebuilds are data, fine, we write EAPI=4 somewhere and be done with
>> it. Anything not having that format is out-of-spec.
> 
> The problem is that right now there's no way to determine the format of
> the data until you already know the format of the data.
Well, we know it's bash.. ;)

> We hack around
> this by not allowing "drastic" format changes, where "drastic" includes
> "using things in newer versions of bash" and "not adding new global
> scope commands".
> 
> The question under discussion is whether we a) keep "what format the
> data is in" as being part of the data, but impose some strange and
> arbitrary conditions on it
Stipulating an allowed set of characters is in no way arbitrary, nor 
strange- we already have similar restrictions on category and package names, 
versions, keywords and USE flags, for example. Requiring that the EAPI 
assignment for a bash .ebuild must be a literal (ie EAPI="foo" or EAPI=foo 
or EAPI='foo') at the start of a line, is not hard to understand; as you 
said ebuild authors already have to deal with lots of other subtle 
restrictions. As Marc Schiffbauer said, EAPI "might be the most important 
constraint in an ebuild at all" (from this and earlier discussion, it's 
clear that it definitely is) -- ebuild developers have to know about it, and 
this is a simple, clear restriction. Michał Górny stated: "The most 
important ebuild variables like EAPI should be readable on sight, without 
having to lookup random variables, functions etc" and in fact, all ebuilds 
in the tree already use a string literal- it just makes more sense from a 
code readability pov, quite apart from anything else.

You mentioned indentation in another mail; afaics there is no problem with 
whitespace at the start of the line.

Ensuring EAPI declaration and sourced value match, has value beyond use in 
EAPI extraction: it's a sanity check that should be performed in any case, 
way before an ebuild hits the tree.

> , b) make a one-time change to have some kind
> of 'header' inside the file describing its format that isn't really part
> of the data itself, or c) admit that GLEP 55 already solved the problem
> and we might as well just fix the issue properly once and for all, even
> if GLEP 55's author is considered by some to be one of Satan's little
> minions.
> 
Regardless of your past behaviour, my objections to GLEP 55 are, and always 
have been, technical: it breaks encapsulation, which once implemented cannot 
be taken back. It results in a mess of filename extensions, which are 
confusing and irrelevant to end-users, as well as making other tools and 
scripts trickier to implement; a simple example: a highlighting editor would 
need to pattern-match the file extension. It's not needed: the simplest, 
least-invasive alternative already works, and should have been adopted years 
ago, when the Council asked for alternatives to be tried. The tree is 
clearly in shape to do so now, though.

Package versions have to be in the filename to avoid collisions, and indeed 
the information is relevant to both end-users and developers. EAPI, while 
vital to the mangler and of immediate concern to developers, matches neither 
of those. Since it is of immediate concern, restricting it to a string 
literal makes sense from both maintenance (which is why it matches tree-
usage) and implementation perspectives. And specifying what characters are 
allowed is a no-brainer; it's odd that that still has not been done, despite 
it also being a requirement for embedding EAPI in filenames.

Your motivation for GLEP-55 states: "In order to get the EAPI the package 
manager needs to source the ebuild." Given a suitable specification, that 
isn't the case. repoman checks and explicit documentation are all that's 
needed beyond that.

As for non-bash ebuilds, I have always agreed with antarus that they should 
simply use a different extension. Adding a new extension per source language 
is a *lot* cleaner than one per EAPI.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)