Misc #20259
open
Proposal to add "ruby --irb" and / or "ruby --start-irb" to start irb (interactive ruby) via ruby (bin/ruby), via the commandline
Description
This issue proposes to add:
a) a commandline flag to bin/ruby that allows the user to start irb,
and
b) allow the user to make use of ruby to start irb, via the commandline (thus, the
proposal's a) and b) are naturally connected to one another, meaning that we would
have a commandline flag for the binary "ruby", and this flag, when invoked, will
start irb, in the current terminal, just as if we would have typed "irb")
Background to this proposal, including prior proposals:
I believe there are prior proposals that are related, such as this one here from
~3 years ago:
https://bugs.ruby-lang.org/issues/17859
by deivid.
Note that my proposal is a bit different: I don't propose that "ruby" would behave
like python here, but instead I would propose that bin/ruby gets a specific flag
such as "--irb" and/or "--start-irb" (the latter is a bit longer to type, so the
former is more convenient, but I also like that the latter, aka --start-irb is more
specific, showing the intent more clearly; and we can add both flags anyway, so
people can just pick what they prefer. I would probably just make an alias such
as "rirb" for "ruby --start-irb" on my local system).
The way I came yesterday to a somewhat similar conclusion as deivid did, shall be
explained next, even though my path is an indirect one.
As some may know, Tim (and others) are creating natalie, a ruby "dialect" (well,
it'll be ruby in the end I believe but right now it does not satisfy the full
ruby specification):
https://github.com/natalie-lang/natalie
Although there are some issues natalie currently has (it's a bit slow right now, for
instance), they did invest quite a lot of time into it and it is slowly shaping up -
at the least presently. More work to be done on satisfying ruby's specification.
Yesterday I compiled natalie from a git checkout and it compiled and installed fine.
I was confused that under bin/ there was only "natalie", but no irb. I may be wrong
but I think in the past I had bin/irb there too. Anyway, that then got me thinking
that I may have made a mistake - but, also, why can't we just use ruby to start
irb, as-is? That is, the executable called "ruby", under bin/ruby.
Yes, this is natalie, not ruby, I understand that. I also fully understand that MRI
ruby having --irb and --start-irb does not change the situation for natalie, jruby,
truffleruby - you name it. I get that, although I should like to point out that they
may often follow suit what MRI ruby decides, so if they have a variant of irb, it
may be likely that they would add the same or similar commandline flags to support
changes in MRI, even if it may take a while (see jruby issue tracker having tons
of todo-entries on github, to keep track of new ruby releases and what changed
between version).
But I was then also wondering why ruby itself would not allow us to start irb in such
a way, via "ruby". I understand that we have bin/irb, so this is not a real problem -
people can just start "irb" normally. And I think we can require irb from a ruby .rb
file just fine, as well, and use irb that way, all fine too. But even then I still
wondered why we can not run irb via "ruby". Is there any reason that speaks against
"ruby --start-irb" starting irb? I don't think the stdlib idea for ruby was to prevent
ruby itself from providing convenience to the user. I also don't propose other gems
to be started like that either, supporting many different commandline flags or
--start=name_of_gem_here; irb is more important, in my opinion, than many other
gems. The key idea for irb is to have "interactive ruby". pry pushed that idea
further, and I think the recent irb releases included some ideas from pry too. ALL
of these focus on an "interactive ruby", no matter the real name (be it irb,
pry or anything else) - just as "python" without arguments focuses on "interactive
python".
If we look at python, python kind of provides two ways to run things: "python foobar.py",
and without argument, the interactive python. Again, I am not proposing to join that
together, different to deivid's proposal, but indeed, it made me question ruby's current
behaviour.
I think python's behaviour to be able to select either way, via "python" itself, is better;
that we are unable to select which behaviour to use via commandline flag, in python, is a
drawback, as jeremy pointed out since he prefers the current ruby heaviour, but via an
additional commandline flag I think we can at the least get python's interactive behaviour
into ruby (that is, IRB; although it should be mentioned that the new IRB is a bit different
to the older IRB, but I leave it at that, since the proposal here is about starting IRB,
not about IRB's behaviour - the latter is for the github project of IRB, rather than MRI's
issue tracker here).
deivid reasoned that python's behaviour is useful for newbies, which I do not doubt. jeremy
said that he prefers the current behaviour of ruby, which is also fine. An explicit commandline
flag for starting irb may be a compromise, but I should like to say that my rationale today
was different from deivid's one, in that I actually really want bin/ruby to give us a SIMPLE
means to start irb, rather than merely "ruby" showing the same behaviour as "python" does,
in regarsd to starting its interactive variant.
Again, I can work around this just fine, using a .rb file to start IRB and so forth, but I
really think having this supported via a simple commandline flag may be more convenient. Of
course, a secondary proposal to this may then be to add another commandline flag to get
to support deivid's suggestion :) - but that would also be for another issue request on the
bugtracker here. For this proposal, I really merely suggest to add --irb and/or --start-irb
(or any other variant that may be more fitting, perhaps --interactive; the name is not so
important, although it should be a convenient name and ideally short. The functionality is
more important than the name.)
Implementation details:
Let's for a moment assume people may find this useful. Then the question is, which irb should
be started when using "ruby --irb"?
Probably the most sensible default option here is to simply use whatever irb version has been
installed on the target computer. Hiroshi Shibata and others worked towards gemifying ruby's
stdlib, so it makes sense that "ruby --start-irb" would use the currently installed irb version,
whatever that is. For most ruby users this is probably the one that came distributed with
whatever ruby version they are using, at the least for modern ruby versions.
Otherwise they may just install a new irb version from e. g.
https://github.com/ruby/irb
or whatever:
gem install irb
installs. And this is then started when they do "ruby --start-irb". So, "ruby --start-irb"
would be exactly the same as the user typing "irb" on the commandline, without any further
arguments.
Of course the user can also start irb via "irb", as-is. So they'd only get an additional
way to start irb. They can continue to use "irb" just fine. All that would change is that
"ruby" itself would get an additional commandline argument, one that starts its "interactive
part".
Anyway - I have no idea how much support the above would find; perhaps if jeremy is active
he could compare it towards deivid's suggestion and comment on it too. I thought about
appending to deivid's suggestion, but the suggestion here is a bit different, so I think
it may be better to propose it as a separate one, even though it is somewhat close to his
proposal, even though it is unrelated (see how I reached that conclusion, which I think is
different than deivid's proposal).
I am not sure if there are even older proposals or not, but there may be. It's also fine
to close this issue here, by the way, to keep the issue tracker list shorter (and perhaps
link it towards deivid's above issue too, if this is closed, which is fine). I kind of
wanted to contribute a bit to the discussion from a different point of view. Perhaps to
avoid having too many open issues, this issue here could be left open for a month or
two, to allow for a bit of more discussion, then it can be closed and e. g. referred to
deivids' issue; and if deivid has time he may comment on the one here or his older
proposal. At any rate, thank you for reading this proposal.
(PS: I filed it under Misc because it did not seem to necessarily be a Feature of the
ruby language itself. Of course it could also fit under Feature, so I was not sure
where to categorize it.)
Updated by