Re: Jinja2 syntax for conditionals (was: Re: Project options and other format enhancements (and dropping "variants"))

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2017-09-21 at 09:31 +0000, Sander Striker wrote:
> On Thu, Sep 21, 2017, 09:15 Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:
> > Replying again to the beginning of this Jinja2 subthread.
> >
> >
> > So I've presented what I think are valid cases against using a
> > predefined thing that is "not a DSL" and as such we do not control, the
> > problems with this are possibly not huge if we look at them more
> > closely - however - the *mere idea* of choosing a potentially more
> > arduous path in the name of a petty shed color has been driving me up
> > the wall as a matter of basic principle.
>
> I'm sorry Tristan, that was definitely not my intent.  My bikeshed comment may have been unfortunate in 
> that respect.

Nah, we were all thinking it and you hit the nail on the head, thats
perfectly fine - I think I mostly needed to identify whether it was in
fact just a matter of shed color or not, I rather think it is now.

Also, sometimes I guess it really matters, as you put it, it's on the
front lawn, the neighbors are bound to be offended by bright yellow and
purple stripes anyway :)

> > That said, I do *like* the fancy proposed light jinja-green for the
> > bike shed; and the more we discuss this, the more I think a vast
> > majority will prefer this kind of syntax (I might buy myself a lot of
> > hours in the future explaining to people that they should not be so
> > damn picky about trivial things, if I just give in now, too, that is
> > value in and of itself).
>
> Right, I'm sort of expecting that kind of syntax to be more broadly liked.  I'm also suspecting it is 
> easier to understand when reading [as opposed to composing] bst files.
>
> > Seems this is the last sticking point of the proposal in general, and
> > if we all want to go python-ish then I'm prepared to give in; as long
> > as it can be guaranteed to *not be a programming language* (so no
> > multiple statements and the like are allowed in a condition, we should
> > not be able to abuse this).
>
> +1 on it not being a programming language.
>
> > Further, we have to make some concessions before hand about the options
> > that this code would be casing.
> >
> > I suppose that if we impose the limitation that BuildStream can *never*
> > get deeply involved in the option declarations and their
> > meanings; cannot ever be allowed to understand the meaning of an
> > option, then the expressions and the nature of the variables tested in
> > those expressions become 100% in the domain of the user; if this is
> > guaranteed to always be the case, then not controlling the parser and
> > expressions is much less of a concern.
> >
> > This *might* cause some issue if BuildStream wants to play smart aleck
> > and do freaky things one would expect it to, like automatically setting
> > some predefined well known built-in options; such as a "bst-arch"
> > option automatically defaulting to the hosts `uname -m` output.
>
> These I would indeed expect to work, just like bst-version, and maybe a few other non-controversial 
> built-ins.
>
> > Or, it might not cause any issue with things like the above, but if
> > rationally we can say that's where the madness stops, it looks like we
> > could live with this third party definition of our expressions format
> > situation.
>
> I think that is sensible (to counter the madness :))
>  
> > The pythony expressions do look cuter; and maybe jinja2 is just so
> > nicely written that we can cleanly just yank the module we want out of
> > it and in-tree it like we're doing with fuse.
> >
> > In any case; we have to close the book on this last week so the time to
> > act is yesterday.
>
> Agreed.  I think there has been enough opinion and argument on the table to make the call.

Certainly.

Thanks to all who have endured through this arduous discussion.

Cheers,
    -Tristan