On Sun, 16 Sep 2012 09:05:28 -0700 Brian Harring <ferri...@gmail.com> wrote: > > Labels doesn't have this problem: it doesn't try to reuse an > > existing syntax precisely because the existing syntax is extremely > > awkward for this kind of thing. > > Labels have a human comprehension problem, and require a fair amount > more work for the various parsers. > > You may not agree on that view, but there seems to be some consensus > on that (as much as one ever gets in gentoo at least).
I've never heard that view coming from anyone who has actually used
labels. It's only come from people who haven't tried using it, and who
have a history of disagreeing with anything that says 'Exherbo' on it.
You're taking about consensus among people who have never tried it
because they don't like it; consensus among people who have tried it is
that the labels syntax is good.
> My intention is a syntax/format that is natural to the dev, and
> doesn't force them to do silly shit.
Labels already solve that. We know because we've got extensive
experience with them. Adoption of labels has been demonstrated to be
easy, both for former Gentoo developers and for people who haven't
previously written ebuilds.
We *know* that labels are easy to learn and easy to use. We also know
that they admit an efficient implementation, that they compose nicely,
that they allow dependencies to be specified accurately and that they
scale to larger numbers of dependency classes.
> > 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.
> 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 ) )
> > 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.
> > 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.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
