Deprecate multi-irb feature

[st0012]

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 IRB doesn't restore context after leaving the nested session #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.

[zenspider]

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

[kml]

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 😉 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

[st0012]

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

[jwkoelewijn]

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.

[ozydingo]

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?

[tompng]

Usability problem of local variable and command is fixed in #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> 

[jwkoelewijn]

Sweet, thanks! 🙌🏼

[jdelStrother]

Something I miss without being able to just run irb everywhere is being able to inspect something that only exists for the duration of a block - eg:

irb(main):002:0> File.open("/etc/hosts") { |f| irb f }
irb#1(#<File:0x000055be023ef240>):001:0> self.size
=> 174

and then being able to iteratively experiment with methods on the object yielded to the block.
(pretending for the moment that File.open doesn't support a blockless variant)

Is there an equivalent version that works without multi-irb?

[EDIT: Oh, maybe I should just be using binding.irb ?

irb(main):001> File.open("/etc/hosts") { |f| binding.irb }
irb(main):001> f.size
=> 1063

]

[nzifnab]

I'm getting this message when I do jobs = Job.find(job_ids) and never used to run into this problem..., am I not allowed to use jobs as a variable name? I've been doing that for 15 years lol.

irb(main):093> jobs = Job.find(job_ids)
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:0x00007f26904fa9a8 run>: running)
=> nil
irb(main):094> js = Job.find(job_ids)
=>
[#<Job:0x00007f26887180d0
...

It's also eating the output somehow, and returning nil? I swear this never used to happen, what's going on here lol.

[tompng]

The jobs = value problem existed in irb-1.13.0 through irb-1.13.2 and already fixed in irb >= 1.14.0