The list rbenv install -l is too long, show latest stable releases by default

[metalefty]

Background

As time passes, list of available ruby versions is growing. However, I think ordinary users hardly install ancient versions such as Ruby 1.8 and Ruby 1.9. Now rbenv install -l became too big and is filled up with obsolete unused versions.

What I did

I implemented new options to show only supported versions.

• rbenv install -L (--list-exclude-eol)
• ruby-build --definitions-exclude-eol

I used warn_eol warn_unsupported flag to determine if the version is EoL'ed.

Result

Now I get significantly compact list.

% ruby-build --definitions | wc -l
     463
% ruby-build --definitions-exclude-eol | wc -l
     186

Also I can easily know which versions are supported. I believe this feature is helpful for most users.

% ruby-build --definitions-exclude-eol |grep ^'[0-9]'
2.5.0-dev
2.5.0-preview1
2.5.0-rc1
2.5.0
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.5.6
2.5.7
2.6.0-dev
2.6.0-preview1
2.6.0-preview2
2.6.0-preview3
2.6.0-rc1
2.6.0-rc2
2.6.0
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.7.0-dev
2.7.0-preview1
2.7.0-preview2
2.7.0-preview3
2.7.0-rc1
2.7.0-rc2
2.7.0
2.8.0-dev

% ruby-build --definitions |grep ^'[0-9]'|less
1.8.5-p52
1.8.5-p113
1.8.5-p114
1.8.5-p115
1.8.5-p231
1.8.6
1.8.6-p36
(snip)

[metalefty]

I'll fix CI test later.

[mislav]

Hi, thank you for the idea!

I definitely agree that it's problematic that the list grows indefinitely and that it starts with all the EOL'd versions and you need to scroll a bunch to get to the recent ones.

However, I'm not convinced that the solution proposed here is the right one. I just don't see myself, or anyone else, routinely passsing the different exclude-eol flags, especially becuse they feel pretty verbose.

How could we make the list by default look nicer? Could we perhaps start with the latest Ruby version and go down to the oldest? That way people don't have to scroll when listing available versions.

[metalefty]

Thanks for the feedback. I don't think the behaviour in my PR, show all versions by default and exclude EoLs by option, is not best. I implemented this with care not to change current behaviour and compatibility. As a result, exclude-eol is not default at first. If you agree to exclude EoLs by default, I would like to do that. However, it is a breaking change.

Regarding order of versions, I prefer current order, old versions appear earlier and new versions later. Because even with exclude-eol, the list should be still longer than terminal size. People will see only the last a few dozens of lines.

I suppose people don't want to scroll up when listing available versions so I think current order is not bad. However, I suppose most people want to install some latest versions of MRI (2.7.x, 2.6.x, 2.5.x) by ruby-build. MRI should come at bottom.

To conclude,

• people want to install the latest some versions of MRI
• show older to newer
• show MRI at bottom

This is current output without piping to less or more.

If MRI comes at bottom, people can install most popular versions without scroll up.

[eregon]

I think it would be nicer to only show each stable version for each interpreter.
ruby-install is very good at this:

$ ruby-install   
Stable ruby versions:
  ruby:
    2.4.9
    2.5.7
    2.6.5
    2.7.0
  jruby:
    9.2.9.0
  rbx:
    4.14
  truffleruby:
    19.3.1
  mruby:
    2.1.0

The data it uses is from https://github.com/postmodern/ruby-versions which is easy to consume.

I would think most ruby-build users either want to install one of these, or they know a specific version and then a full list is unhelpful, they could just type it and see if ruby-build accepts it.

Having a full list somewhere is maybe still useful in some cases, but seems rather unhelpful in most cases, especially when it's so long.

The short list could be shown just on ruby-build or on ruby-build -l/--list for example.

[eregon]

Since we'd probably want to compute the short list from the full list of definitions, maybe we could simply group by "development branch" which is "major.minor" for MRI and just "major" for other rubies, and show the latest of each such group.

[mislav]

@eregon I like these suggestions!

I wonder to which level should we keep backwards compatibility with rbenv install -l and ruby-build --definitions in case scripts use them?

[eregon]

Re compatibility, I think ruby-build --definitions could be kept as-is as the full list. If a script uses this output, they most likely use ruby-build --definitions, not the output of rbenv.

I think changing rbenv install -l to be the short output would be acceptable.
And then we can add ruby-build -l which would be the same short output, so then we get -l as a consistent flag on both tools for the short list of versions :)

[metalefty]

Thanks, I'll make a change.

[metalefty]

@mislav @eregon What do you think about if short list should include -preview -dev -rc versions?

[metalefty]

Done. One more change is remained that not to show -preview -dev -rc` versions in the short list. If that is not needed, it can be merged.

[jasonkarns]

Thought: what if EOL versions of ruby were extracted out of this repo into a separate repo? rbenv will pull definitions from all plugins (matching the share/ruby-build/ path)...

Users who need to install EOL versions would just need to clone the other plugin repo. Everyone else, by default, would have the more manageable list of versions.

[eregon]

@metalefty The current state of the PR seems to only exclude EOL versions, that's still a very long list.

What do you think of having an output similar to what I mentioned in #1402 (comment) ?
That is only the latest stable releases (e.g., 2.4.9/2.5.7/2.6.5/2.7.0 for MRI, just latest release for others) + -dev.

I think -preview/-rc should be hidden in the short list, they are clearly less relevant than the full .0 release which comes after. Could be interesting to have preview/rc which don't have a .0 release yet, but not sure it's worth the effort.

[metalefty]

Thanks for the feedback. Regarding showing the latest stable releases, I think it is a good idea but at least I'm not very interested in that. The biggest thing I wanted to do is do not show ancient Rubies such as 1.8, 1.9. It's not worth the effort for me.

If someone else implement that feature, I welcome his/her contribution. I will not disagree.

[metalefty]

Removed -rc, -preview, -dev versions from the short list and fixed CI.

[eregon]

@metalefty Could you post the full list before and after in a gist?

I think an output like ruby-install would be a very valuable improvement (only show recommended versions, not old versions with known bugs), but I understand it's also more complicated to implement.
It also doesn't seem ideal to change twice the -l output.

@mislav What do you think?

[metalefty]

@eregon here it is.

diff: https://gist.github.com/metalefty/c4beba4fe2d3c20cbf6511abae3e7386#file-diff-txt
full: https://gist.github.com/metalefty/c4beba4fe2d3c20cbf6511abae3e7386#file-full-txt
short: https://gist.github.com/metalefty/c4beba4fe2d3c20cbf6511abae3e7386#file-short-txt

[metalefty]

To show only the latest stable releases, some tags need to be added in definition files to indicate the version is a latest stable release. Like share/ruby-build/2.2.0 has warn_eol tag.

It is not difficult and I'm OK with implementing filtering list using such tags. However, it makes complicated to maintain definitions. When a new version released (2.6.6 for example), maintainer should remove latest_stable tag from 2.6.5 and attach to 2.6.6. I concern who does it.

[eregon]

Thanks, that goes from 463 lines to 150 lines. A good improvement, but still quite long and requires a lot of scrolling. Probably very few are interested e.g. in the full list of 100+ releases of rbx-3.x.

Note that MRI 2.4 is not EOL yet. It will be soon, but I think we shouldn't exclude warn_unsupported, only warn_eol.

However, it makes complicated to maintain definitions.

My idea to implement that is to not to use a tag (that causes conflicts and is hard to maintain, indeed) but to only use the filename of each definition. From there we can find which Ruby implementation it is and the version by splitting around the first -. Then we need a special rule for MRI to keep the latest of each major.minor. For others, we can simply show the latest (according to sort_versions) non-rc version.

[metalefty]

Sounds good. I'm close to implementing it.

[metalefty]

@eregon I finally got the short list like the following. Does this satisfy you?

2.5.7
2.6.5
2.7.0
jruby-9.2.9.0
maglev-1.0.0
mruby-2.1.0
rbx-3.107
truffleruby-19.3.1

ADDED: If you want to include MRI 2.4.9, I'll make an additional change. It's a piece of cake.

[mislav]

@metalefty Nice!

I wonder if we should add a note to the output saying: "To see all available versions, use --list-all", or something like that.

[metalefty]

I agree to add that user-friendly note. The message should be on stderr not to break machine parsability.

[metalefty]

Resolved conflicts.

[metalefty]

Merge?

[eregon]

@mislav Could you merge this PR? I think it's ready.
(and any minor improvement can always be done incrementally later)

[metalefty]

Can you consider a timeout for @mislav ?

2 months have already past since the last time he gave me feedback. I would say 2 months are enough to wait him back. I don't think we need to wait for him anymore.

[eregon]

I agree, I think 2 approvals is enough for this, and it can always be refined later, let's merge.

[eregon]

Released as https://github.com/rbenv/ruby-build/releases/tag/v20200518

It works well for me locally.