1 |
On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote: |
2 |
> On Sun, 16 Sep 2012 06:52:11 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > The live version of the doc is available at |
5 |
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html |
6 |
> |
7 |
> I think you're being a bit glib with your dismissal of the labels |
8 |
> parsing scheme. You've got the following problems, that labels don't |
9 |
> have: |
10 |
> |
11 |
> You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that". |
12 |
|
13 |
x? ( !x? ( dep ) ) already exists syntactically. dep:build? ( |
14 |
dep:run? ( blah ) ) is no different, so yes, I dismiss it- frankly |
15 |
with prejudice since you keep bringing that example up but ignoring |
16 |
that it's not a new issue (plus ignoring that it never occurs in the |
17 |
wild because it's a self-solving issue). |
18 |
|
19 |
|
20 |
> Labels doesn't have this problem: it doesn't try to reuse an existing |
21 |
> syntax precisely because the existing syntax is extremely awkward for |
22 |
> this kind of thing. |
23 |
|
24 |
Labels have a human comprehension problem, and require a fair amount |
25 |
more work for the various parsers. |
26 |
|
27 |
You may not agree on that view, but there seems to be some consensus |
28 |
on that (as much as one ever gets in gentoo at least). |
29 |
|
30 |
|
31 |
> You say there's an implict "build,run". This can't be an implicit |
32 |
> "dep:build,run? ( )" using that syntax, however, since then you |
33 |
> wouldn't be able to put a dep:post? inside it by the above. |
34 |
|
35 |
You're misunderstanding; you're thinking about it as to how exheres |
36 |
labels are done which is basically |
37 |
build+run: ${DEPENDENCIES} |
38 |
|
39 |
One thing to keep in mind here; I don't mind making the parser do some |
40 |
extra work if it's easier on devs to deal with (including |
41 |
aesthetically; like it or not, dependencies is needed, and screaming |
42 |
"labels are the one true religion" isn't going to get us to where we |
43 |
need to go- pragmatic compromise will). |
44 |
|
45 |
Either way, in the absense of an explicit dep context, dep:build,run? |
46 |
is assumed. The parser/visitation implementation is admittedly more |
47 |
complex, but it's not in the realm of 'hard'. This is assuming a |
48 |
non-shit implementation mind you. |
49 |
|
50 |
Either way, my focus here is on the human, as I've stated. |
51 |
|
52 |
|
53 |
> So again |
54 |
> you've got a special case to deal with simply because of the syntax -- |
55 |
> your syntax doesn't correspond directly to the meaning of dependencies. |
56 |
|
57 |
"doesn't correspond directly to the meaning of dependencies" is a |
58 |
vague assertion; back that one up. I'm assuming you're complaining |
59 |
that conditionals are being used (the "but they're not USE flags!" bit |
60 |
which is a subjective view of the conditional namespace). |
61 |
|
62 |
If that's not what you're referencing, then frankly I'll just go with |
63 |
"explain to me how this same critique doesn't apply to labels". |
64 |
|
65 |
|
66 |
> There's also the issue of what negations do at the top level... |
67 |
|
68 |
Yeah, I did skimp on that one; technically speaking, negations aren't |
69 |
required if they prove too much of a pain in the ass. Negation at the |
70 |
top level could be interpretted two ways: |
71 |
|
72 |
1) negating against all possible dep types; thus a !dep:build? would |
73 |
be dep:post,run? . Too slick in my view, but who knows, othes may |
74 |
think it straight forward. |
75 |
|
76 |
2) Treat it as a negation of the implicit dep:build,run; meaning |
77 |
!dep:build? would be dep:run?. |
78 |
|
79 |
Unsure of which is preferably at this juncture. |
80 |
|
81 |
> You discourage grouping of dependencies by the use flag that selects |
82 |
> them (see xscreensaver in your examples). Logically, "xscreensaver |
83 |
> related things" belong together. |
84 |
|
85 |
I do not discourage grouping. The example is an automated |
86 |
conversion, as explicitly mentioned in the doc. |
87 |
|
88 |
A secondary condensing of those deps I'll add to make clear it's |
89 |
supported. |
90 |
|
91 |
|
92 |
> Your negation example also tries to |
93 |
> bring related dependencies together. But it's a mess. What if one of |
94 |
> the dependencies was a build dependency, and one a run dependency? |
95 |
> You'd end up with something silly like this: |
96 |
> |
97 |
> dep:build,run? ( |
98 |
> !dep:run? ( dev-util/diffball ) |
99 |
> !dep:build? ( dev-util/bsdiff ) |
100 |
> ) |
101 |
|
102 |
Ciaran, we use a fucking bash format. We lost the ability to block |
103 |
silly idiocy long ago via that choice. |
104 |
|
105 |
As said, 'x? ( !x? ( dep ) )' already exists, despite being dumb. The |
106 |
beauty of it however is that the syntax rules themselves make it such |
107 |
that it doesn't ever actually come up in real world usage- the dep |
108 |
wouldn't be used fundamentally. |
109 |
|
110 |
My intention is a syntax/format that is natural to the dev, and |
111 |
doesn't force them to do silly shit. If they choose to do silly shit, |
112 |
that's on their head; trying to explicitly ban all possible dumb uses |
113 |
just makes the rules worse via increased complexity. |
114 |
|
115 |
Also, just to be clear, this critique applies to exheres labels just |
116 |
the same. That example, rewritten to drop the negations is thus: |
117 |
|
118 |
dep:build,run? ( |
119 |
dep:build? ( dev-util/diffball ) |
120 |
dep:run? ( dev-util/bsdiff ) |
121 |
) |
122 |
|
123 |
Yep. That's pretty dumb. But no less retarded than someone doing the |
124 |
following in labels: |
125 |
|
126 |
build+run: |
127 |
build: dev-util/diffball |
128 |
run: dev-util/bsdiff |
129 |
|
130 |
Which I'll note isn't banned in your usage, despite the idiocy of such |
131 |
a construct. |
132 |
|
133 |
|
134 |
|
135 |
> Your syntax also prevents the following: |
136 |
> |
137 |
> DEPENDENCIES="foo? ( $(make_foo_deps blah) )" |
138 |
|
139 |
Err, no it doesn't. I think you're reading too literally into the |
140 |
example mplayer translation I put in the doc- again, that was just a |
141 |
quicky, automated form, you can push dep:blah down beneath |
142 |
conditionals as necessary/desired. |
143 |
|
144 |
If you see something claiming otherwise, or implying otherwise in the |
145 |
glep, please tell me exactly where so I can fix the wording. |
146 |
|
147 |
> |
148 |
> and would encourage something like this instead: |
149 |
> |
150 |
> DEPENDENCIES=" |
151 |
> dep:build? ( foo? ( $(make_foo_build_deps blah) ) ) |
152 |
> dep:run? ( foo? ( $(make_foo_run_deps blah) ) ) |
153 |
> dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) ) |
154 |
> |
155 |
> which makes it much harder for the foo.eclass authors to switch what |
156 |
> kinds of dependencies they use. For example, if foo.eclass starts |
157 |
> needing an install dependency, your syntax requires every foo user to |
158 |
> be updated, whereas labels does not. To get around that, you'd have to |
159 |
> allow deeply embedded dep: blocks. |
160 |
|
161 |
This critique is based on the same misunderstanding, just to be clear. |
162 |
|
163 |
|
164 |
> You're also still speaking in terms of "rendering DEPEND" etc. |
165 |
|
166 |
Babysteps. First switch the internals to DEPENDENCIES, render from |
167 |
that to *DEPEND; in doing so, it's minimally disruptive for the PM, |
168 |
and for devs. |
169 |
|
170 |
> That's |
171 |
> not really what we want, though. As you've observed, a lot of atoms are |
172 |
> in both DEPEND and RDEPEND. Conceptually, it makes much more sense to |
173 |
> consider such an atom to be a single dependency that is both a build |
174 |
> and a runtime dependency than it does to consider it as two unrelated |
175 |
> dependencies. This is especially the case now that we have := slot |
176 |
> dependencies. |
177 |
|
178 |
Agreed, but we're not going to get to where we want without going |
179 |
through transition phases; at the PM level, minimally these |
180 |
enhancements: |
181 |
|
182 |
1) first, collapse dependencies down, than render the *DEPEND views, |
183 |
thus enabling easy and quick initial integration; effectively |
184 |
no impact on the api/functionality of the PM at this phase. |
185 |
2) Start converting the internals of the PM over such that it |
186 |
operates, directly from that parsed tree, rathrer having to |
187 |
operate on a flatten/reduced/rendered version of it for each |
188 |
context. |
189 |
3) Once that's in place, start teaching the resolver how to make |
190 |
better decisions via the better dependency groupping. |
191 |
|
192 |
That's the rough roadmap for PM's were this to be added, exempting |
193 |
integration of any new dependency types. |
194 |
|
195 |
For devs, they're not going to migrated at the flip of a switch. Thus |
196 |
the same general transition approach; |
197 |
|
198 |
1) switch the focus to DEPENDENCIES via collapsing |
199 |
depend/rdepend/pdepend into it. This allows existing code to work |
200 |
in EAPI5 (or whichever this lands in). |
201 |
2) New dependency forms should be added to DEPENDENCIES only; this is |
202 |
a bit of a carrot to get folks to migrate. |
203 |
3) As ebuilds/eclasses get further along, and <EAPI5 support gets |
204 |
increasingly dropped, devs are encouraged (and hopefully willing |
205 |
since the syntax should make their lives easier) to migrate to the |
206 |
new form. |
207 |
4) Some point down the line when we've neared an appropriate critical |
208 |
mass, we discontinue the no longer necessary *DEPEND appending into |
209 |
DEPENDENCIES; basically deprecate and/then ban *DEPEND in the EAPI |
210 |
of that day. *DEPEND fades into the dust, same as how implicit |
211 |
RDEPEND=${RDEPEND-${DEPEND}} was phased out. |
212 |
|
213 |
|
214 |
> Ultimately, it comes down to the observation that the flag? ( ) syntax |
215 |
> is strongly nested and hierarchical, but dependency roles aren't. |
216 |
|
217 |
There is a bit of truth in that views on flag? ( ) vs the random-ass |
218 |
context labeling (which is hierarchical- keep in mind your stack |
219 |
pushing/popping confusion). |
220 |
|
221 |
That said, just because it *is*, doesn't mean it has to get in the |
222 |
way. Devs are already quite familiar w/ the hierarchical/nesting |
223 |
behaviour of flag? ( ); I seriously doubt they are going to have |
224 |
problems making dep:* work. |
225 |
|
226 |
Basically, yes, there are some limitations; do they matter? Not |
227 |
really, no. |
228 |
|
229 |
Is it a perfect scheme? While a neat reuse of existing syntax, no, |
230 |
it's not perfect. |
231 |
|
232 |
But it's realistic, and *doable*. That counts for a fucking helluva |
233 |
lot more than chasing the perfect solution. |
234 |
|
235 |
I expect you'll inject some rant, but frankly REQUIRED_USE is a good |
236 |
example of what I'm talking about; the synax sucks, it's a bit |
237 |
painful, but it filled a needed gap and got the job done- 10% of EAPI4 |
238 |
ebuild are using it after all (please skip the required-use rant also, |
239 |
whatever the flaws, one cannot argue w/ the usage). |
240 |
|
241 |
|
242 |
> Labels can give all the advantages of your proposal (including the |
243 |
> backwards compatibility, if that's desired), but without the need to |
244 |
> shoehorn the idea into an unsuitable syntax. |
245 |
|
246 |
If you want your proposal to go anywhere, you're going to need a |
247 |
better transition plan then "and.... then devs convert their |
248 |
ebuilds/eclasses". I'd suggested it prior, but no traction there. |
249 |
|
250 |
Either way, you push your syntax, I'll push mine; I'm fine w/ devs |
251 |
choosing the one that best fits their flow. |
252 |
|
253 |
~harring |