1 |
Pardon the delay; got busy with work, plus to actually address your |
2 |
claims re: labels (or refute, as I intend to do)... data was |
3 |
necessary. |
4 |
|
5 |
So I went and got the data. :) |
6 |
|
7 |
Analysis was done roughly 09/17 or so; just looping back and |
8 |
commenting now however. |
9 |
|
10 |
|
11 |
On Sun, Sep 16, 2012 at 05:59:21PM +0100, Ciaran McCreesh wrote: |
12 |
> > > Your syntax also prevents the following: |
13 |
> > > |
14 |
> > > DEPENDENCIES="foo? ( $(make_foo_deps blah) )" |
15 |
> > |
16 |
> > Err, no it doesn't. I think you're reading too literally into the |
17 |
> > example mplayer translation I put in the doc- again, that was just a |
18 |
> > quicky, automated form, you can push dep:blah down beneath |
19 |
> > conditionals as necessary/desired. |
20 |
> > |
21 |
> > If you see something claiming otherwise, or implying otherwise in the |
22 |
> > glep, please tell me exactly where so I can fix the wording. |
23 |
> |
24 |
> The point is that nesting prevents composition. Labels are context |
25 |
> insensitive, which allows groups of dependencies to be added anywhere, |
26 |
> whereas dep: blocks can only be added if the surrounding groups are |
27 |
> specified in a particular way. |
28 |
|
29 |
Fun fact; peoples usage of labels in exherbo is thus: |
30 |
|
31 |
build+run: |
32 |
set of deps |
33 |
run: |
34 |
set of deps/conditionals/etc |
35 |
|
36 |
You get the idea. Technically, each block is usually wrapped in |
37 |
()... which frankly is a sign that the context switch third party |
38 |
code can introduce is problematic. Basically, y'all are |
39 |
already using labels in exactly the fashion I propose, just |
40 |
with different synax. |
41 |
|
42 |
I couldn't find a *single* instance of the following in usage in any git.exherbo repo: |
43 |
|
44 |
build+run: |
45 |
dep1 |
46 |
x? ( |
47 |
dep2 |
48 |
test: |
49 |
dep3 |
50 |
) |
51 |
|
52 |
Ie, a nested override. |
53 |
|
54 |
Exherbo deps themselves basically dispute the claim that nesting |
55 |
somehow blocks people from doing composition; fact is, y'all can do |
56 |
nesting/context switching of a label w/in a block, but y'all don't at |
57 |
all. This strongly makes me think you're either blowing smoke up |
58 |
folks asses or that you're chasing perfection ignoring the realities |
59 |
of how this is used on the ground. |
60 |
|
61 |
Now, if there are actually examples of it in use in y'alls trees- |
62 |
(ones that aren't added after I send this email mind you ;) ) please |
63 |
point them out. Offhand, there's actually 4 pkgs that do |
64 |
stacking/nesting of deps, although it's accidental and doesn't |
65 |
actually do it for gain. They are: |
66 |
|
67 |
dev-haskell/language-c[=0.3.2]::haskell |
68 |
dev-haskell/language-javascript[=0.5.2]::haskell |
69 |
kde/kdemultimedia[~scm]::kde |
70 |
kde/kdemultimedia[=4.8.5]::kde |
71 |
|
72 |
basically |
73 |
DEPENDENCIES=" |
74 |
( build: some deps |
75 |
# dev forgot to close the block |
76 |
$(some dep_generator that forces a label immediately, per the norm) |
77 |
)" |
78 |
|
79 |
While the norm is |
80 |
DEPENDENCIES=" |
81 |
( build: some deps ) |
82 |
( $(some dep_generator that forces a label immediately) )" |
83 |
|
84 |
Interesting sidenote btw; every usage I've found is directly |
85 |
translatable to my proposal, w/out any loss of expression in use. |
86 |
|
87 |
Now, it's possible I fucked up. I strongly doubt it however. Please |
88 |
provide examples either way- else y'alls own dependencies disprove |
89 |
your claims about nesting being evil. |
90 |
|
91 |
Either way, the data for that is at |
92 |
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt |
93 |
|
94 |
|
95 |
> > 1) first, collapse dependencies down, than render the *DEPEND views, |
96 |
> > thus enabling easy and quick initial integration; effectively |
97 |
> > no impact on the api/functionality of the PM at this phase. |
98 |
> |
99 |
> Specification in terms of rendering has a huge problem, though. |
100 |
> Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does |
101 |
> this do? |
102 |
> |
103 |
> || ( dep:build? ( a ) dep:run? ( b ) ) |
104 |
|
105 |
Honestly, I was waiting for you to bring this up :) |
106 |
|
107 |
You're conflating two different things here; |
108 |
1) someone being a dumb ass and writing what's effectively a || ( |
109 |
atom) block, just doing so in a manner w/out any reason to do so. |
110 |
|
111 |
2) Your ongoing jihad against || (), specifically the occasionally |
112 |
valid complaint that build/rdepend different means the resolver can |
113 |
get stuck in certain pathways when slots are involved, abi, etc. |
114 |
|
115 |
Either way, in my proposal, I'm not going to single that out and try |
116 |
blocking it. The rendered version of it is still stable, albeit if |
117 |
it's build/run it's unlikely to be desired if there is ABI involved |
118 |
(for non ABI, specifically self-bootstrapping codebases, I suspect |
119 |
someone could come up with a valid construct- sed has something |
120 |
similar if memory serves). |
121 |
|
122 |
Worth noting, the following idiocy is valid: |
123 |
|
124 |
x? ( dev-util/diffball ) |
125 |
!dev-util/diffball |
126 |
|
127 |
Which is stupid, but syntactically correct. Nor is this a new issue, |
128 |
thus I don't particularly agree with your approach of trying to sink |
129 |
the proposal via an orthogonal problem. |
130 |
|
131 |
This is why we have QA tools. |
132 |
|
133 |
|
134 |
> > > Ultimately, it comes down to the observation that the flag? ( ) |
135 |
> > > syntax is strongly nested and hierarchical, but dependency roles |
136 |
> > > aren't. |
137 |
> > |
138 |
> > There is a bit of truth in that views on flag? ( ) vs the random-ass |
139 |
> > context labeling (which is hierarchical- keep in mind your stack |
140 |
> > pushing/popping confusion). |
141 |
> |
142 |
> There's not any stack confusion in practice. Labels only have slightly |
143 |
> complicated rules to allow every side case to be covered. You're taking |
144 |
> the "don't do that" approach to nesting weirdness; labels go the |
145 |
> "specify it precisely" route instead. |
146 |
|
147 |
In practice, all usages explicitly go out of their way to protect |
148 |
themselves from the invoking context, and they use labels *exactly the |
149 |
same way as dep:build,run? ( blah )* would be used. |
150 |
|
151 |
Basically the only real world benefit I've seen of labels vs what I've |
152 |
proposed is a *slight* collapsing of the tree- although that is more |
153 |
than offset by the fact all dep generating functions introduce () |
154 |
barriers to protect the invoking scope from their label adjustments. |
155 |
|
156 |
Clarifying, this is better in labels: |
157 |
""" |
158 |
build+run: |
159 |
blah |
160 |
run: |
161 |
monkeys |
162 |
""" |
163 |
equivalent in my proposal would be |
164 |
""" |
165 |
blah |
166 |
dep:run? ( monkeys ) |
167 |
""" |
168 |
|
169 |
The difference there isn't exactly world shattering, so it's not a |
170 |
strong arguing point for labels. |
171 |
|
172 |
|
173 |
> > > Labels can give all the advantages of your proposal (including the |
174 |
> > > backwards compatibility, if that's desired), but without the need to |
175 |
> > > shoehorn the idea into an unsuitable syntax. |
176 |
> > |
177 |
> > If you want your proposal to go anywhere, you're going to need a |
178 |
> > better transition plan then "and.... then devs convert their |
179 |
> > ebuilds/eclasses". I'd suggested it prior, but no traction there. |
180 |
> |
181 |
> Your "rewrite *DEPEND" approach can just as easily be used with labels. |
182 |
|
183 |
Just the same as the real world usage of labels could just as easily |
184 |
be done via dep:blah. |
185 |
|
186 |
Not sure it's worth continuing this discussion point frankly; there is |
187 |
equivalence for all real world usage. Not really in dispute (you'll |
188 |
try I'm sure, but without actual backing examples this time around I'm |
189 |
not particularly interested in listening). |
190 |
|
191 |
If what you've got to say is "you can do this in labels, and I think |
192 |
you should labels"; ok, noted, end of discussion. |
193 |
|
194 |
Other points I'm interested in; the mentioning of "what does |
195 |
!build:test? ( blah ) mean while in implicit build,run" for example |
196 |
was useful and a valid critique (one I've not yet addressed in the |
197 |
doc); stuff like that you've got a better chance killing my proposal |
198 |
then continuing with the "yes but labels are better than sliced bread. |
199 |
you just don't understand" angle of discussion ;) |
200 |
|
201 |
Either way, via |
202 |
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt |
203 |
, I think it's pretty clear labels in real world usage aren't bringing |
204 |
anything to the tabel that we wouldn't have via my proposal; that |
205 |
leaves labels as just a different syntax (perhaps aesthetically more |
206 |
pleasing at first glance, but the label stacking bit via exheres |
207 |
analysis is proven to be something people explicitly go out of their |
208 |
way to protect against; meaning the aesthetics have a mental |
209 |
model cost). |
210 |
|
211 |
~harring |