Future of `readline.rb`
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?
Updated by rubyFeedback (robert heiler) 3 months ago
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:
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:
(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.
Updated by Eregon (Benoit Daloze) about 2 months ago
Seems odd for a standard library to attempt to load a non-standard library first, and fallback to loading a standard library.
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
Updated by hsbt (Hiroshi SHIBATA) about 2 months ago
I wonder what is the future of readline.rb? It still tries to load readline.so by default. Is this intended behavior?
readline.rb is same as
yaml.rb for migrating backend.
reline is mostly compatible
libreadline. But we don't rush to rewrite
reline in Ruby 3.3.
Updated by mame (Yusuke Endoh) about 2 months ago
- 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
readlinelibrary if it is available.
- We see no benefit in removing it and forcing people to explicitly change to