1 |
On Sun, 16 Sep 2012 09:05:28 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > Labels doesn't have this problem: it doesn't try to reuse an |
4 |
> > existing syntax precisely because the existing syntax is extremely |
5 |
> > awkward for this kind of thing. |
6 |
> |
7 |
> Labels have a human comprehension problem, and require a fair amount |
8 |
> more work for the various parsers. |
9 |
> |
10 |
> You may not agree on that view, but there seems to be some consensus |
11 |
> on that (as much as one ever gets in gentoo at least). |
12 |
|
13 |
I've never heard that view coming from anyone who has actually used |
14 |
labels. It's only come from people who haven't tried using it, and who |
15 |
have a history of disagreeing with anything that says 'Exherbo' on it. |
16 |
You're taking about consensus among people who have never tried it |
17 |
because they don't like it; consensus among people who have tried it is |
18 |
that the labels syntax is good. |
19 |
|
20 |
> My intention is a syntax/format that is natural to the dev, and |
21 |
> doesn't force them to do silly shit. |
22 |
|
23 |
Labels already solve that. We know because we've got extensive |
24 |
experience with them. Adoption of labels has been demonstrated to be |
25 |
easy, both for former Gentoo developers and for people who haven't |
26 |
previously written ebuilds. |
27 |
|
28 |
We *know* that labels are easy to learn and easy to use. We also know |
29 |
that they admit an efficient implementation, that they compose nicely, |
30 |
that they allow dependencies to be specified accurately and that they |
31 |
scale to larger numbers of dependency classes. |
32 |
|
33 |
> > Your syntax also prevents the following: |
34 |
> > |
35 |
> > DEPENDENCIES="foo? ( $(make_foo_deps blah) )" |
36 |
> |
37 |
> Err, no it doesn't. I think you're reading too literally into the |
38 |
> example mplayer translation I put in the doc- again, that was just a |
39 |
> quicky, automated form, you can push dep:blah down beneath |
40 |
> conditionals as necessary/desired. |
41 |
> |
42 |
> If you see something claiming otherwise, or implying otherwise in the |
43 |
> glep, please tell me exactly where so I can fix the wording. |
44 |
|
45 |
The point is that nesting prevents composition. Labels are context |
46 |
insensitive, which allows groups of dependencies to be added anywhere, |
47 |
whereas dep: blocks can only be added if the surrounding groups are |
48 |
specified in a particular way. |
49 |
|
50 |
> 1) first, collapse dependencies down, than render the *DEPEND views, |
51 |
> thus enabling easy and quick initial integration; effectively |
52 |
> no impact on the api/functionality of the PM at this phase. |
53 |
|
54 |
Specification in terms of rendering has a huge problem, though. |
55 |
Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does |
56 |
this do? |
57 |
|
58 |
|| ( dep:build? ( a ) dep:run? ( b ) ) |
59 |
|
60 |
> > Ultimately, it comes down to the observation that the flag? ( ) |
61 |
> > syntax is strongly nested and hierarchical, but dependency roles |
62 |
> > aren't. |
63 |
> |
64 |
> There is a bit of truth in that views on flag? ( ) vs the random-ass |
65 |
> context labeling (which is hierarchical- keep in mind your stack |
66 |
> pushing/popping confusion). |
67 |
|
68 |
There's not any stack confusion in practice. Labels only have slightly |
69 |
complicated rules to allow every side case to be covered. You're taking |
70 |
the "don't do that" approach to nesting weirdness; labels go the |
71 |
"specify it precisely" route instead. |
72 |
|
73 |
> > Labels can give all the advantages of your proposal (including the |
74 |
> > backwards compatibility, if that's desired), but without the need to |
75 |
> > shoehorn the idea into an unsuitable syntax. |
76 |
> |
77 |
> If you want your proposal to go anywhere, you're going to need a |
78 |
> better transition plan then "and.... then devs convert their |
79 |
> ebuilds/eclasses". I'd suggested it prior, but no traction there. |
80 |
|
81 |
Your "rewrite *DEPEND" approach can just as easily be used with labels. |
82 |
|
83 |
-- |
84 |
Ciaran McCreesh |