Pardon the delay; got busy with work, plus to actually address your
claims re: labels (or refute, as I intend to do)... data was
necessary.
So I went and got the data. :)
Analysis was done roughly 09/17 or so; just looping back and
commenting now however.
On Sun, Sep 16, 2012 at 05:59:21PM +0100, Ciaran McCreesh wrote:
> > > Your syntax also prevents the following:
> > >
> > > DEPENDENCIES="foo? ( $(make_foo_deps blah) )"
> >
> > Err, no it doesn't. I think you're reading too literally into the
> > example mplayer translation I put in the doc- again, that was just a
> > quicky, automated form, you can push dep:blah down beneath
> > conditionals as necessary/desired.
> >
> > If you see something claiming otherwise, or implying otherwise in the
> > glep, please tell me exactly where so I can fix the wording.
>
> The point is that nesting prevents composition. Labels are context
> insensitive, which allows groups of dependencies to be added anywhere,
> whereas dep: blocks can only be added if the surrounding groups are
> specified in a particular way.
Fun fact; peoples usage of labels in exherbo is thus:
build+run:
set of deps
run:
set of deps/conditionals/etc
You get the idea. Technically, each block is usually wrapped in
()... which frankly is a sign that the context switch third party
code can introduce is problematic. Basically, y'all are
already using labels in exactly the fashion I propose, just
with different synax.
I couldn't find a *single* instance of the following in usage in any
git.exherbo repo:
build+run:
dep1
x? (
dep2
test:
dep3
)
Ie, a nested override.
Exherbo deps themselves basically dispute the claim that nesting
somehow blocks people from doing composition; fact is, y'all can do
nesting/context switching of a label w/in a block, but y'all don't at
all. This strongly makes me think you're either blowing smoke up
folks asses or that you're chasing perfection ignoring the realities
of how this is used on the ground.
Now, if there are actually examples of it in use in y'alls trees-
(ones that aren't added after I send this email mind you ;) ) please
point them out. Offhand, there's actually 4 pkgs that do
stacking/nesting of deps, although it's accidental and doesn't
actually do it for gain. They are:
dev-haskell/language-c[=0.3.2]::haskell
dev-haskell/language-javascript[=0.5.2]::haskell
kde/kdemultimedia[~scm]::kde
kde/kdemultimedia[=4.8.5]::kde
basically
DEPENDENCIES="
( build: some deps
# dev forgot to close the block
$(some dep_generator that forces a label immediately, per the norm)
)"
While the norm is
DEPENDENCIES="
( build: some deps )
( $(some dep_generator that forces a label immediately) )"
Interesting sidenote btw; every usage I've found is directly
translatable to my proposal, w/out any loss of expression in use.
Now, it's possible I fucked up. I strongly doubt it however. Please
provide examples either way- else y'alls own dependencies disprove
your claims about nesting being evil.
Either way, the data for that is at
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt
> > 1) first, collapse dependencies down, than render the *DEPEND views,
> > thus enabling easy and quick initial integration; effectively
> > no impact on the api/functionality of the PM at this phase.
>
> Specification in terms of rendering has a huge problem, though.
> Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does
> this do?
>
> || ( dep:build? ( a ) dep:run? ( b ) )
Honestly, I was waiting for you to bring this up :)
You're conflating two different things here;
1) someone being a dumb ass and writing what's effectively a || (
atom) block, just doing so in a manner w/out any reason to do so.
2) Your ongoing jihad against || (), specifically the occasionally
valid complaint that build/rdepend different means the resolver can
get stuck in certain pathways when slots are involved, abi, etc.
Either way, in my proposal, I'm not going to single that out and try
blocking it. The rendered version of it is still stable, albeit if
it's build/run it's unlikely to be desired if there is ABI involved
(for non ABI, specifically self-bootstrapping codebases, I suspect
someone could come up with a valid construct- sed has something
similar if memory serves).
Worth noting, the following idiocy is valid:
x? ( dev-util/diffball )
!dev-util/diffball
Which is stupid, but syntactically correct. Nor is this a new issue,
thus I don't particularly agree with your approach of trying to sink
the proposal via an orthogonal problem.
This is why we have QA tools.
> > > Ultimately, it comes down to the observation that the flag? ( )
> > > syntax is strongly nested and hierarchical, but dependency roles
> > > aren't.
> >
> > There is a bit of truth in that views on flag? ( ) vs the random-ass
> > context labeling (which is hierarchical- keep in mind your stack
> > pushing/popping confusion).
>
> There's not any stack confusion in practice. Labels only have slightly
> complicated rules to allow every side case to be covered. You're taking
> the "don't do that" approach to nesting weirdness; labels go the
> "specify it precisely" route instead.
In practice, all usages explicitly go out of their way to protect
themselves from the invoking context, and they use labels *exactly the
same way as dep:build,run? ( blah )* would be used.
Basically the only real world benefit I've seen of labels vs what I've
proposed is a *slight* collapsing of the tree- although that is more
than offset by the fact all dep generating functions introduce ()
barriers to protect the invoking scope from their label adjustments.
Clarifying, this is better in labels:
"""
build+run:
blah
run:
monkeys
"""
equivalent in my proposal would be
"""
blah
dep:run? ( monkeys )
"""
The difference there isn't exactly world shattering, so it's not a
strong arguing point for labels.
> > > Labels can give all the advantages of your proposal (including the
> > > backwards compatibility, if that's desired), but without the need to
> > > shoehorn the idea into an unsuitable syntax.
> >
> > If you want your proposal to go anywhere, you're going to need a
> > better transition plan then "and.... then devs convert their
> > ebuilds/eclasses". I'd suggested it prior, but no traction there.
>
> Your "rewrite *DEPEND" approach can just as easily be used with labels.
Just the same as the real world usage of labels could just as easily
be done via dep:blah.
Not sure it's worth continuing this discussion point frankly; there is
equivalence for all real world usage. Not really in dispute (you'll
try I'm sure, but without actual backing examples this time around I'm
not particularly interested in listening).
If what you've got to say is "you can do this in labels, and I think
you should labels"; ok, noted, end of discussion.
Other points I'm interested in; the mentioning of "what does
!build:test? ( blah ) mean while in implicit build,run" for example
was useful and a valid critique (one I've not yet addressed in the
doc); stuff like that you've got a better chance killing my proposal
then continuing with the "yes but labels are better than sliced bread.
you just don't understand" angle of discussion ;)
Either way, via
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt
, I think it's pretty clear labels in real world usage aren't bringing
anything to the tabel that we wouldn't have via my proposal; that
leaves labels as just a different syntax (perhaps aesthetically more
pleasing at first glance, but the label stacking bit via exheres
analysis is proven to be something people explicitly go out of their
way to protect against; meaning the aesthetics have a mental
model cost).
~harring
