1 |
Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that |
2 |
a regex is not required during the scan, and nor is restricting it to the |
3 |
first N lines, though the latter may be desirable and could trivially |
4 |
exclude comment and whitespace-only or empty lines. |
5 |
|
6 |
Ciaran McCreesh wrote: |
7 |
>Michael Orlitzky wrote: |
8 |
>> Fair enough, but aren't you arguing the opposite point with Zac? If |
9 |
>> ebuilds are data, fine, we write EAPI=4 somewhere and be done with |
10 |
>> it. Anything not having that format is out-of-spec. |
11 |
> |
12 |
> The problem is that right now there's no way to determine the format of |
13 |
> the data until you already know the format of the data. |
14 |
Well, we know it's bash.. ;) |
15 |
|
16 |
> We hack around |
17 |
> this by not allowing "drastic" format changes, where "drastic" includes |
18 |
> "using things in newer versions of bash" and "not adding new global |
19 |
> scope commands". |
20 |
> |
21 |
> The question under discussion is whether we a) keep "what format the |
22 |
> data is in" as being part of the data, but impose some strange and |
23 |
> arbitrary conditions on it |
24 |
Stipulating an allowed set of characters is in no way arbitrary, nor |
25 |
strange- we already have similar restrictions on category and package names, |
26 |
versions, keywords and USE flags, for example. Requiring that the EAPI |
27 |
assignment for a bash .ebuild must be a literal (ie EAPI="foo" or EAPI=foo |
28 |
or EAPI='foo') at the start of a line, is not hard to understand; as you |
29 |
said ebuild authors already have to deal with lots of other subtle |
30 |
restrictions. As Marc Schiffbauer said, EAPI "might be the most important |
31 |
constraint in an ebuild at all" (from this and earlier discussion, it's |
32 |
clear that it definitely is) -- ebuild developers have to know about it, and |
33 |
this is a simple, clear restriction. Michał Górny stated: "The most |
34 |
important ebuild variables like EAPI should be readable on sight, without |
35 |
having to lookup random variables, functions etc" and in fact, all ebuilds |
36 |
in the tree already use a string literal- it just makes more sense from a |
37 |
code readability pov, quite apart from anything else. |
38 |
|
39 |
You mentioned indentation in another mail; afaics there is no problem with |
40 |
whitespace at the start of the line. |
41 |
|
42 |
Ensuring EAPI declaration and sourced value match, has value beyond use in |
43 |
EAPI extraction: it's a sanity check that should be performed in any case, |
44 |
way before an ebuild hits the tree. |
45 |
|
46 |
> , b) make a one-time change to have some kind |
47 |
> of 'header' inside the file describing its format that isn't really part |
48 |
> of the data itself, or c) admit that GLEP 55 already solved the problem |
49 |
> and we might as well just fix the issue properly once and for all, even |
50 |
> if GLEP 55's author is considered by some to be one of Satan's little |
51 |
> minions. |
52 |
> |
53 |
Regardless of your past behaviour, my objections to GLEP 55 are, and always |
54 |
have been, technical: it breaks encapsulation, which once implemented cannot |
55 |
be taken back. It results in a mess of filename extensions, which are |
56 |
confusing and irrelevant to end-users, as well as making other tools and |
57 |
scripts trickier to implement; a simple example: a highlighting editor would |
58 |
need to pattern-match the file extension. It's not needed: the simplest, |
59 |
least-invasive alternative already works, and should have been adopted years |
60 |
ago, when the Council asked for alternatives to be tried. The tree is |
61 |
clearly in shape to do so now, though. |
62 |
|
63 |
Package versions have to be in the filename to avoid collisions, and indeed |
64 |
the information is relevant to both end-users and developers. EAPI, while |
65 |
vital to the mangler and of immediate concern to developers, matches neither |
66 |
of those. Since it is of immediate concern, restricting it to a string |
67 |
literal makes sense from both maintenance (which is why it matches tree- |
68 |
usage) and implementation perspectives. And specifying what characters are |
69 |
allowed is a no-brainer; it's odd that that still has not been done, despite |
70 |
it also being a requirement for embedding EAPI in filenames. |
71 |
|
72 |
Your motivation for GLEP-55 states: "In order to get the EAPI the package |
73 |
manager needs to source the ebuild." Given a suitable specification, that |
74 |
isn't the case. repoman checks and explicit documentation are all that's |
75 |
needed beyond that. |
76 |
|
77 |
As for non-bash ebuilds, I have always agreed with antarus that they should |
78 |
simply use a different extension. Adding a new extension per source language |
79 |
is a *lot* cleaner than one per EAPI. |
80 |
|
81 |
Regards, |
82 |
Steve. |
83 |
-- |
84 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |