FLAVORS for Ruby

[Koichiro Iwao]

On Mon, Sep 16, 2019 at 08:54:17AM -0600, Adam Weinberger wrote:
> On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao <meta at freebsd.org> wrote:
> >
> > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote:
> > > The issue is that FLAVORS has added a substantial (and painful) complexity to python ports and python.mk. It means that a number of people have had to be hyper-vigilant and watch commits closely to catch errors introduced when people utilize the paradigm incorrectly. It’s a bitter pill, but it’s accepted because the use-case for multiple concurrent python versions is essential.
> > >
> > > As Antoine said, inconsistency isn’t a strong enough use case. Which brings us back to the original question: is there a specific use-case for concurrent ruby that makes the substantial increase in cognitive load, complexity, and monitoring worth it?
> >
> > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions
> > is essential?
> 
> We're going in circles here. I've for the third time now that what
> we'd need to get on board is a use case, a description of the end-user
> problem that we're trying to solve.
> 
> What you've provided (for the fourth time in this thread) is a straw
> man argument. What other languages have is irrelevant. We are much
> less concerned with "consistency" than with solving end-user problems
> in a way that fits the specific use case.
> 
> Steve seemed interested in the idea. I'd explore it with him, and I
> hope you are able to make it happen. I'm done here.

Thanks. I see a gap between you and me but I'll give it a try anyway
with swills.

You:  If there's no valid reasons, don't do it.
Me:   If there's no invalid reasons, try it.

I believe that the reason Ruby don't have FLAVORS is just nobody worked
on that. In fact, swills worked on that a little.

BTW, if I can do something only necessary, what a boring life.

-- 
meta <meta at FreeBSD.org>