1 |
On Sun, Sep 30, 2012 at 09:30:18PM +0100, Ciaran McCreesh wrote: |
2 |
> On Sun, 30 Sep 2012 13:14:53 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > > That's largely because there are a lot of former Gentoo developers |
5 |
> > > there who all said "oh, yeah, I forgot we could do it the other way" |
6 |
> > > when this was pointed out... |
7 |
> > |
8 |
> > I analyzed *all* exheres on git.exherbo. |
9 |
> > |
10 |
> > To be crystal clear, these include your packages. |
11 |
> > |
12 |
> > You yourself didn't use nested labels. So either the author of |
13 |
> > labels 'forgot' he could use it, or just didn't find the nesting |
14 |
> > actually useful. |
15 |
> |
16 |
> That's a rather disingenuous claim, considering how none of the |
17 |
> packages I maintain have any non-trivial dependencies... You could |
18 |
> equally well say that every single package I maintain makes use of |
19 |
> nested labels in every single place where they're relevant. |
20 |
|
21 |
Admittedly, that was a punch nearing the belt or a bit below; that |
22 |
said it's not disenguous. |
23 |
|
24 |
Reality is, our current form can handle deps generally fine- what you |
25 |
label as trivial is the vast majority- I argue effectively all. |
26 |
|
27 |
And I intentionally gave you a way to disprove that; find real world |
28 |
dependency examples to disprove it. |
29 |
|
30 |
|
31 |
> > So... real world usage removes one of the core arguments of labels, |
32 |
> > leaving it just as "it's a new syntax/aesthetically more pleasing" in |
33 |
> > comparison to dep:build? ( blah ) form. |
34 |
> > |
35 |
> > Not expecting you'll agree with that statement based on the facts of |
36 |
> > y'alls own repo... so if you're going to retort, bust out actual |
37 |
> > examples from eithe trees, where nesting would be preferable to the |
38 |
> > form people use now please; else just drop it (-your- own usage of |
39 |
> > labels disproves your claim; thus why I want actual examples now if |
40 |
> > that point will be debated any further). |
41 |
> |
42 |
> It's not just that it's more aesthetically pleasing. There are two |
43 |
> arguments favouring labels over use abuse. |
44 |
> |
45 |
> The first is that it doesn't have perverse behaviour associated with it |
46 |
> like your misappropriation of use conditionals does. If you put labels |
47 |
> deep in a tree, it's well defined. If you put your conditionals |
48 |
> anywhere except the top level, crazy stuff happens. |
49 |
|
50 |
This statement of yours however is fairly disenguous; label behaviour |
51 |
when nested suffers the same mental parsing oddity (wait, we're in |
52 |
build context, and this is test? Wtf happens there?). With 'use |
53 |
abuse' however, the situation is clear: |
54 |
|
55 |
dep:build,run? ( x? ( dep:test? ( blah ) foon ) monkeys ) |
56 |
|
57 |
Means that 'blah' target doesn't show up. Which is the *same* as what |
58 |
happens if someone did thus in our existing syntax: |
59 |
|
60 |
x? ( !x? ( blah ) ) |
61 |
|
62 |
Worth noting, you didn't ban that from exherbo; you left that to sort |
63 |
itself out, same as I'm doing for dep:blah flags. Were I punching |
64 |
below the belt, the word 'hypocritical' would likely be involved. |
65 |
|
66 |
|
67 |
> The second is that it starts the conceptual shift from "cat/pkg is a |
68 |
> build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is |
69 |
> required for build and run". |
70 |
|
71 |
Fairly weak argument at best; you're claiming that via labels, |
72 |
"contextually they know it's these deps" in comparison to via |
73 |
dep:build "contextually they know it's exposed only in build". |
74 |
|
75 |
Same difference. |
76 |
|
77 |
|
78 |
> > Bluntly, you want something that is academically possible, but |
79 |
> > pragmatically/realistically unneeded- meaning the gains are basically |
80 |
> > not there, but the costs most definitely are. |
81 |
> |
82 |
> No, I want something where things that are different look different. |
83 |
> Dependency types are nothing like use flags, so they shouldn't look the |
84 |
> same. |
85 |
|
86 |
I'll buy that argument, and to some degree- agree. |
87 |
|
88 |
I just view that as academic wankery without real world gain. |
89 |
|
90 |
So like I said, academically possible, but |
91 |
pragmatically/unrealistically unneded. |
92 |
|
93 |
No amount of arguing is going to dissuade me on that view either, |
94 |
although real world tree examples *might*- aka, stop talking, go |
95 |
analyzing. |
96 |
|
97 |
|
98 |
> > Either way, this is gentoo, we're talking about the ebuild format; |
99 |
> > just the same as everyone shredded mgorny's ass for proposing we |
100 |
> > mangle atom syntax w/out gain, and proposal you push for the deptree |
101 |
> > changing, has to have significant gains for changing the existing |
102 |
> > form; aesthetics at a cost aren't enough. |
103 |
> |
104 |
> The gain is that you have a syntax designed for what's being |
105 |
> represented, not an existing syntax abused to sort of (but not |
106 |
> quite, because it's still defined in terms of rendering down) do new |
107 |
> things. |
108 |
> |
109 |
> Really, all it takes to see that your syntax is bad is one tiny little |
110 |
> example: |
111 |
> |
112 |
> dep:build? ( dep:run? ( cat/pkg ) ) |
113 |
|
114 |
x? ( !x? ( cat/pkg ) ) |
115 |
|
116 |
Outlaw that in paludis/exherbo, and *perhaps* I'd listen to you. |
117 |
|
118 |
You're going into broken record mode; the fact people can do stupid |
119 |
shit if they're willingly trying to abuse the syntax isn't much of an |
120 |
argument- especially considering the PM can handle it either way, |
121 |
rendering it out to a noop. |
122 |
|
123 |
|
124 |
> There shouldn't be any need to add in a repoman check to catch that |
125 |
> kind of thing. The problem is entirely caused by bad syntax design. |
126 |
> Implementing labels is not difficult, and the extra cost is worth it to |
127 |
> get a good design. |
128 |
|
129 |
As I've said, there isn't a need for repoman checks. It's *suggested* |
130 |
since as I've stated, the underlying idiocy should be spotted in our |
131 |
existing deps. |
132 |
|
133 |
That said, repoman isn't necessary; such a construct solves itself via |
134 |
the deps dropping out; and before you try arguing that, your argument |
135 |
effectively would be based on "if someone specifies the deps wrong..." |
136 |
which means they're already up shit creek. |
137 |
|
138 |
Either way, pulling another "done with this thread" bit to wrap this |
139 |
up; you don't like the proposal, got it. |
140 |
|
141 |
In my proposal, I am addressing labels; will fold in your claims, but |
142 |
those claims basically are shit- however, if you *did* find a |
143 |
conflicting nested example that wasn't contrived, preferablly |
144 |
multiple, I'd like those examples so I can include them into the |
145 |
proposal (give labels a fair hand, basically). |
146 |
|
147 |
I don't think you're going to find any, let alone one; some |
148 |
artificially structured ones perhaps, but I'm not interested in those- |
149 |
I'm looking for real world deps where conflicting nested is the best |
150 |
form. |
151 |
|
152 |
Go find 'em; either way, moving on from the current discussion form |
153 |
(also known as "broken record mode"). |
154 |
|
155 |
cheers- |
156 |
~harring |