FLAVORS for Ruby

[Steve Wills]

Hi,

On 9/17/19 2:40 AM, Mathieu Arnold wrote:
> 
> What we are all trying to say is that adding flavors for ruby will have
> a big impact on build time and ressources required for building.
> 
> If all you want is to have ruby flavors for the kicks of it, then I am
> glad to tell you that no, it will not be done.
> 
> Now, the question is, why would someone need to have ruby flavors?
> 
> The answer cannot be "because it should be fun" or "there is no reason
> there should not be".
> 
> Give us a real reason about why it would be required.
> 

We have multiple versions of Ruby, we should provide the gems for each 
version. Right now, there is no way for users of Ruby 2.4 to install gem 
packages except to change the default ruby and then build their own 
packages. We want people to have fewer reasons to build their own 
packages, not more.

We keep the latest Ruby as not default because it tends to have more 
bugs and gems lag, and the older version of Ruby is available because 
some gems tend to lag really badly. So, users do have legitimate reasons 
for using the non-default versions of Ruby. Also, upstream supports 
latest and two versions back.

It wasn't until Ruby 2.6 was out that GitLab even supported 2.5, to give 
just one example.

So, we have those versions of Ruby, and they should be usable, and that 
includes installing gems via pkg.

There's the point that maybe we should only package gems that are needed 
by other things, which I can understand, but don't know if I necessarily 
agree with, because then you have users confused on what the "right" way 
to install a gem is. "Oh, this one is packaged because something else in 
ports needs it, so use the pkg, but this other one isn't packaged, so 
you have to use gem."

And I'd think the same applies to python modules or perl modules, etc. 
One could ask, why not provide flavors for all versions of python, that 
is, 3.5, 3.6 and 3.7, along with the 2.7 ones as well, but to me that 
doesn't seem quite necessary because the compatibility is better there, 
as far as I can tell. But, I wouldn't be opposed to it personally, if 
someone did make the argument in favor of it. Same with Perl and 
especially things that depend on Java.

But that's all beside the point, really.

Steve