Bug #19866: Future of `readline.rb`

• Status: Rejected
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: -
• ruby -v: ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux]
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

[vo.x (Vit Ondruch)]

I wonder what is the future of readline.rb? It still tries to load readline.so by default. Is this intended behavior? I'd say that instead, it should rather fire a deprecation warning and load reline. Or maybe the whole readline gem should be completely removed?

[rubyFeedback (robert heiler)]

I believe hsbt may be able to answer your question. reline is probably the future anyway.
https://github.com/ruby/readline has not received an update in ~2 years, for instance.

I do, however had, disagree conceptually that:

require 'readline'

would/should require reline, though. Users who do say may 100% want to get readline, so a
forceful redirection towards reline may NOT be what ALL users want to have or see if they
use require 'readline'. I still have some legacy code that uses readline; while I am fine
to transition towards reline (and I still think reline could need better documentation),
I do not think it is a good idea to force another library into the way how users use
something or specify loading of library xyz, to then suddenly get library abc when they
clearly did not specify this.

It's not up to the ruby core team, IMO, to force deprecations onto users like this, e. g.
to force them towards reline even if they specified "require 'readline'" specifically. That
just would not seem right to me.

Let people decide on their own if they want to switch towards reline; readline-ruby
is only available externally, anyway - see:

https://github.com/ruby/readline

(I understand that this is not 100% what hsbt wrote, but it is my opinion that when
people do require 'xyz' that ruby should try to load xyz, rather than abc because
some random developer tries to force people to use that suddenly. Since ruby core
already uses reline, that should it be, and then the proper way to get it used is
via require 'reline', rather than require 'readline'.)

I am not entirely sure a deprecation notice is necessary either. IMO it would be
better to recommend reline officially and let people transition towards it at their
own pace. ruby-core can use reline as it is just fine, without any problem.

In regards to removal: I actually thought readline was already removed and put onto
github, but I understand that part of your question; in this case I would think it
is best to remove readline from ruby core, and let the readline-ext be available as
gem people can install as-is. We have had a similar situation with psych and syck
(for yaml) and that was fine. I used syck for a few years after psych became default,
and then one day I was just using psych and stopped using syck altogether. I do not
remember any deprecation warnings were necessary there.

[Eregon (Benoit Daloze)]

From https://bugs.ruby-lang.org/issues/19883#change-104825

Seems odd for a standard library to attempt to load a non-standard library first, and fallback to loading a standard library.

Agreed.
I think either lib/readline.rb should only use reline and not try readline-ext,
or lib/readline.rb should be deprecated/warn, and users then adapt to require 'readline-ext'/require 'reline'

[hsbt (Hiroshi SHIBATA)]

I wonder what is the future of readline.rb? It still tries to load readline.so by default. Is this intended behavior?

It's intentional. readline.rb is same as yaml.rb for migrating backend.

reline is mostly compatible libreadline. But we don't rush to rewrite readline to reline in Ruby 3.3.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to hsbt (Hiroshi SHIBATA)

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

Discussed at the dev meeting, and agreed that the current status be maintained.

• Dependency on external libraries is not very happy, but not a problem itself. Actually, set.rb had longly depended on rbtree gem.
• As long as it is named readline.rb, it should respect readline library if it is available.
• We see no benefit in removing it and forcing people to explicitly change to require "reline".