Deprecate multi-irb feature

st0012 commented 1 year ago

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.

zenspider commented 10 months ago

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

kml commented 9 months ago

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

st0012 commented 5 months ago

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

jwkoelewijn commented 5 months ago

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 commented 4 months ago

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 commented 4 months ago

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>

jwkoelewijn commented 4 months ago

Sweet, thanks! 🙌🏼

jdelStrother commented 1 month ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

ruby / irb