binding.pry doesn't fire when it's on the last line of a program

[squarism]

Failing case:

gem install pry-byebug

# test.rb
require 'pry'
binding.pry

Test: ruby test.rb. No pry shell opens.

Passing case:
gem uninstall pry-byebug

Or, add a line with assignment. Oddly enough, ending lines of comments or simply an ending line of 1 doesn't workaround this.

# test.rb
require 'pry'
binding.pry
a = 1

Test: ruby test.rb. The pry shell opens.

The workaround is pretty simple. Ever since moving to ruby 2 and getting rid of pry-nav, I've just got in the habit of doing this. Logging an issue in case this is unexpected. 🍰

[deivid-rodriguez]

Hi @squarism, thanks for the report. I'm aware of this issue, I had a similar report in byebug recently (deivid-rodriguez/byebug#98). I'll try to think of something to workaround this in the future, but it is not a priority...

[rf-]

This is the same issue as #35. I didn't realize that this was still happening after 6e1c9a1 (I guess now it's only happening at the end of a script instead of the end of a block?). This is a common use case for Pry, so it would be nice to have it working.

[idanci]

Rolled back to 1.3.2 only because of this. :(

[deivid-rodriguez]

Hi @rf-! Yes, same issue, but only for end of script.

Since this issue was opened I've been thinking about what to do with pry-byebug. I was a byebug user who wanted some extra REPL functionality so I developed it to fullfil my own needs, but I didn't understand that most of the user base were actually the opposite: pry users wanting some stepping functionality. I should have probably been more careful about this. The current situation is that I hardly ever use pry-byebug, so I feel less motivated to mantain software I don't use. :(

In any case, I propose 2 alternatives:

• Make pry-byebug an "official" pry plugin (move it to pry/pry-byebug) and get someone from the pry community to mantain it.
• If nobody volunteers for 1, I'll eventually get to this, but I really don't know when that's going to be.

As I workaround while this is sorted out (for people who don't want to stick to the 1.x series), I suggest adding

gem `pry-byebug`, require: false

to Gemfile, and then doing

require 'pry-byebug'; binding.pry

normally but doing

require 'pry'; binding.pry

when at the last line of your program.

[squarism]

Interesting. Just for the record, I found pry-byebug through pry-nav's README which recommended pry-byebug since pry-nav is (planned to be) abandoned. I didn't even know what byebug is! 😛

Thanks for the require tip, that's helpful for project style work although sometimes you don't have a Gemfile (scripts / bin / whatever). Not trying to dissuade you from your proposals while you are at the same time commenting that you are looking for motivation.

The workaround for the last line doesn't act as a workaround.

$ ruby -v
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin13.0] 

$ cat test.rb
fruit = [
  { name: 'Apple', color: 'red', from_tree: true },
  { name: 'Orange', color: 'orange', from_tree: true },
  { name: 'Tomato', color: 'red', from_tree: false }
]
require 'pry'; binding.pry

$ gem list pry
pry (0.10.1)
pry-byebug (2.0.0)
pry-doc (0.6.0)

When running this, it exits. No pry shell.

$ ruby test.rb
$ echo $?
0

Interestingly, running test.rb with the pry command goes into pry's source code. Hmm.

pry test.rb

From: ~.rvm/gems/ruby-2.1.5/gems/pry-0.10.1/lib/pry/pry_instance.rb @ line 356 Pry#evaluate_ruby:

    351: def evaluate_ruby(code)
    352:   inject_sticky_locals!
    353:   exec_hook :before_eval, code, self
    354:
    355:   result = current_binding.eval(code, Pry.eval_path, Pry.current_line)
 => 356:   set_last_result(result, code)
    357: ensure
    358:   update_input_history(code)
    359:   exec_hook :after_eval, result, self
    360: end

But then it exits.

pry> code
=> "require 'pry'; binding.pry\n"
pry> Pry.eval_path
=> "(pry)"

Maybe I could compare states and dig into this to see the difference. Hmm.

Anyway:

1. Byebug by itself is a simple alternative which might work.
2. This gem is still solid gold. It gives ruby devs a killer IDE-like feature.
3. Debugging gems should probably all have require false in the Gemfile? In this case, pry loads plugins automatically anyway right?

I'm still trying to find the exact combination of gem versions that replicates the (off-topic) pry start up problem.

[deivid-rodriguez]

@squarism Sorry for the false workaround, I didn't know pry would load plugins automatically, and just assumed that would work...

And thanks for your valuable comments! I think require: false for debugging gems is a somewhat good practice but not really that important. At least with byebug I've never noticed any significant difference in performance when booting my apps.

[rf-]

@deivid-rodriguez Thanks for giving your perspective on the "byebug plus REPL" vs. "Pry plus stepping" thing. This is really the same problem as the one-letter aliases, I think. As a Pry user, I would normally expect a plugin to stay out of the way unless I'm specifically trying to use it. On the other hand, it makes perfect sense that someone coming from the byebug side would want to make their Pry experience as byebug-like as possible.

Anyway, I'm not sure anyone on the Pry team (including me) is going to want to commit to maintaining this project. Given that that's the case, and that you aren't using it, I wouldn't blame you at all for taking a while to fix this edge case.

[rf-]

Re: the require: false workaround not working, you can put Pry.config.should_load_plugins = false in your .pryrc to disable automatic plugin loading.

[deivid-rodriguez]

Yep, same problem as the aliases. Thanks for understanding, I'll way until someome wants to take over or until I find time myself. At least we have a valid workaround now!

[banister]

@deivid-rodriguez can you explain how to disable this behaviour? is it an easy change? If you can give me some guidance on reverting it back to the normal pry behaviour i'll take this on :)

[deivid-rodriguez]

@banister It's been a while since I don't play with this code, but the change was introduced in the commit pointed out by @rf- in #35. The thing is I like the current behavior and I'd like to keep it and fix this edge case, but it's not an easy one...

[banister]

@deivid-rodriguez is it possible we could make this a config option and users could choose their behaviour? If possible, could we have teh default config to be the normal pry behaviour and for people who prefer your behaviour they could explicitly set it in their ~/.pryrc?

The unfortunate situation is that nearly everyone uses pry-byebug with pry (as it's an awesome gem, thanks! :), but it dramatically changes the standard/expected behaviour for most pry users. I would really really like it if we could have the old behaviour the standard.

Is this an acceptable compromise? I hope so!

[banister]

@deivid-rodriguez oh i just heard that you fixed it for the case where binding.pry is added on the last line of a method, that'll definiteily fix the 90% case.

Is it possible you could push out a new gem with this fix in it? I think that would reduce the majority of confusion, awesome 👍

John

[deivid-rodriguez]

@banister I've been a bit reluctant to release because I haven't used last master myself in any app, and the current test suite doesn't give me enough confidence. Let me try the gem against an app in the next days and I'll release if everything is working fine. Or if you can confirm this yourself, I'll release right now! Does this sound reasonable?

[deivid-rodriguez]

@banister done!