irb icon indicating copy to clipboard operation
irb copied to clipboard

Deprecate multi-irb feature

Open st0012 opened this issue 1 year ago • 7 comments

Plan

  • Print deprecation warnings on these commands: irb, jobs, fg, and kill in the next minor release
  • Completely remove those commands in v2.0.0

Reasons

  • It's concept highly overlaps with workspace commands like chws, pushws...etc.
  • It spawns a new thread for every new new session, which conflicts with the upcoming irb-debug integration
  • But most importantly, we can't find any practical use for this feature and the cost of maintaining its compatibility with other features is high
    • For example, it will require the solution of #650 to support multi-thread irb sessions too

Feedback wanted

If you use the multi-irb feature and don't want to see it deprecated from IRB, please leave a comment below to explain your use case of it. It will help us assess this plan.

st0012 avatar Jul 22 '23 13:07 st0012

Please consider reusing the old command names. chws is just... not good.

zenspider avatar Jan 24 '24 23:01 zenspider

Hi. I find irb command to be useful as an equivalent of pry cd. For example when debugging session starts in irb console (like rails console - testing on staging case), not by putting binding.irb in the tested file.

bin/rails console

# assume it's part of the application
class Greeter
  def hello = "Hello, World!"
end

g = Greeter.new
irb g # <-----------------
Multi-irb commands are deprecated [...]
irb#1(#<Greeter:0x00007faa7b850188>):001> hello
=> "Hello, World!"

Ctrl-D to get back.

UPDATE: OK, just realized that it's ~exactly~ what chws is for :wink: Only more complex to remember the syntax:

pushws cwws
# => [main]
chws g
# => #<Greeter:0x00007f29077f5c38>
hello
# => "Hello, World!"
popws
# => []

Is there a way to go back without having first to push current workspace to the stack?

pry example:

[3] pry(main)> cd g
[4] pry(#<Greeter>):1> hello
# => "Hello, World!"
[5] pry(#<Greeter>):1> cd ..
[6] pry(main)> 

My impression is that cd, cd .. is the human-friendly interface, while workspace commands are generally building blocks of it exposed to the user (missed one layer of abstraction).

https://github.com/ruby/irb?tab=readme-ov-file#commands

kml avatar Feb 15 '24 11:02 kml

@kml Thanks for the feedback 🙂 I'm adding a simpler cd command in #971

st0012 avatar Jun 16 '24 18:06 st0012

I love how this got implemented.... Now whenever I try to assign to an instance variable with the name jobs it now prints a message and doesn't actually create the var... brilliant.

jwkoelewijn avatar Jun 28 '24 05:06 jwkoelewijn

This implementation is a bit overly aggressive. As @jwkoelewijn points out, it breaks any code we might type or copy-paste that uses a jobs instance variable:

worker (local) > jobs = Job.all
Multi-irb commands are deprecated and will be removed in IRB 2.0.0. Please use workspace commands instead.
If you have any use case for multi-irb, please leave a comment at https://github.com/ruby/irb/issues/653
#0->irb on main (#<Thread:0x0000ffff8239a7b0 run>: running)
=> nil
worker (local) > jobs
Multi-irb commands are deprecated and will be removed in IRB 2.0.0. Please use workspace commands instead.
If you have any use case for multi-irb, please leave a comment at https://github.com/ruby/irb/issues/653
#0->irb on main (#<Thread:0x0000ffff8239a7b0 run>: running)
=> nil

Is there a way we can not break assignment to a variable named jobs?

ozydingo avatar Jul 30 '24 18:07 ozydingo

Usability problem of local variable and command is fixed in https://github.com/ruby/irb/pull/961 and released

# irb -v
irb 1.14.0 (2024-07-06)
# irb
irb(main):001> jobs = [1, 2, 3]
=> [1, 2, 3]
irb(main):002> jobs
=> [1, 2, 3]
irb(main):003> 

tompng avatar Aug 01 '24 19:08 tompng

Sweet, thanks! 🙌🏼

jwkoelewijn avatar Aug 02 '24 04:08 jwkoelewijn