Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring <ferringb@gmail.com>]

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