Hi @brauliomartinezlm !

As I commented here, it's in my TODO list to review compatibility with pry-remote. I'm not sure whether it will work or not, but feedback like yours seems to indicate that it doesn't. In any case, I'll review this as soon as I can.

Cheers!

@deivid-rodriguez thanks a lot! I try to help if I have some spare time.

Great!!

I experience the same issue, if pry-remote even works at all. Sometimes I get the behaviour described in this ticket: Mon-Ouie/pry-remote#58

In that case pry-remote does not work at all, showing the context of the PryRemote::Server#run method in the rails server log rather than dropping in the pry-remote command.

👍 this is pretty huge for me. I love pry-byebug a lot but I can't use it locally since I have to test with Unicorn.

👍 Same issue for me (using a Vagrant image locally for development)

Is there some way I/we (everyone with this issue) could help with getting this compatibility added?

Using the latest version 2.0.0 of pry-byebug from Github this is what happens when I try to connect with pry-remote:

12:52:50 web.1    | [pry-remote] Waiting for client on druby://127.0.0.1:9876
12:52:56 web.1    | [pry-remote] Client received, starting remote session
12:52:56 web.1    | [pry-remote] Remote session terminated
12:52:56 web.1    | [pry-remote] Ensure stop service
12:52:56 web.1    |
12:52:56 web.1    | Frame number: 0/140
12:52:56 web.1    |
12:52:56 web.1    | From: /home/vagrant/.gem/ruby/2.1.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 321 Object#remote_pry:
12:52:56 web.1    |
12:52:56 web.1    |     319: def remote_pry(host = PryRemote::DefaultHost, port = PryRemote::DefaultPort, options = {})
12:52:56 web.1    |     320:   PryRemote::Server.new(self, host, port, options).run
12:52:56 web.1    |  => 321: end

Clone/fork both repos and start researching. If you need help let me know. 👍

pry-byebug version 1.3.3 works great with pry-remote, so I'm pinned there for now.

This helped us get running again. Thank you @nessur.

👍

👍 I'm still seeing this issue with pry-byebug. I'd love to see an update that lets them work together.

Any traction on this issue? I am not getting any love from pry-byebug v.1.3.3, v.3.1, v.3.3 with POW and pry-remote v.0.1.8

Nope.

Ok, unless it is really necessary to use pry-remote--e.g. you are doing some pair programming with someone in another city, there is a work around in regard to getting pry-byebug working with POW.
By using the proxy feature of POW, you can create the following in ~/.pow instead of a symlink:

echo 3000 > ~/.pow/basename $PWD``

...doing above from your app directory.

I am doing this with

zeus server

and it is working great. And now I am back to having functionality of pry from pry-byebug,
or using byebug if I wish. Fantastic!

And the pair programming option with POW and byebug is still available with this configuration that Starr Horne came up with:

# config/initializers/byebug.rb

require 'byebug/core'
if Rails.env.development?
  Byebug.start_server 'localhost', ENV.fetch("BYEBUG_SERVER_PORT", 1048).to_i
end

...then:

bundle exec byebug -R localhost:1048

from command line and you're right as rain.

You would just use the normal symlink in ~/.pow in the second example.

Cheers!
jet

@nessur's fix (using version 1.3.3) works for me:

rails (5.0.0.1)
pry-remote (0.1.8)

@deivid-rodriguez have you got any news about compatibility pry-byebug with pry-remote? It's running very well with pry-byebug(version 1.3.3) but I wanna update the gems later.

Any thoughts here? We're seeing the same issue with pry-byebug 1.3.3, byebug 2.7.0 and pry-remote 0.1.8.

For what it's worth here is the exact output we're seeing:

[2] pry(#<Frontend>)> next

From: /usr/local/bundle/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 211 PryRemote::Server#run:

    206: def run
    207:   setup
    208:
    209:   Pry.start(@object, @options.merge(:input => client.input_proxy, :output => client.output))
    210: ensure
 => 211:   teardown
    212: end

It's like it is nexting in the pry process, not in the application.

Unfortunately pry-remote is the best (only?) solution for using pry in a docker-compose setup with multiple ruby applications in the stack. It would be great if it worked well.

Workaround

Use Byebug.start_server and byebug -R.

You don't need pry-remote, pry, pry-nav, or pry-remote. You don't need any pry-stuff. All you need is byebug.

It's not well documented, but it works. See Nicholas Gronow's instructions on SO: https://stackoverflow.com/a/25823241/567762

This issue is four years old and the problem described by @brauliomartinezlm, @jeffutter and others is still present.

I just ran into this issue with pry-byebug 8.2.4 and pry-remote 0.1.8.

Same. So far the only solution is use pry-nav instead of pry-byebug

@deivid-rodriguez 👋 I took a look at this and bisected the issue down to 49de00c. That's the first bad commit where pry-remote no longer works. I guess that probably doesn't help a lot because unfortunately lots of changes have happened since then so I'm not really sure where to go from here to help track this issue down.

@chrisarcand Thanks for investigating. Unfortunately I can't seem to find time & will to have a look at this... 😞 Sorry.

The commit you point to is also the cause of other issues users of this gem usually find, specially pry users. I suggest you have a look at #75. Maybe if you rebase that and get it working against latest master, issues will be fixed, since that PR basically makes the behavior introduced by the offending commit optional.

I have the same problem with pry-byebug 3.6.0 and pry-remote 0.1.8.

One thing I found out is that changing the value in Byebug.current_context.step_out(4, true) ( pry_processor.rb) from 4 to 5 fixes the issue, but only for binding.remote_pry. Once I use binding.pry in the same place it all breaks. It seems that using binding.remote_pry adds one more layer to step out from. This is the stack I got with binding.pry:

step_out 1: /home/sloneorzeszki/lab/pry-byebug/lib/byebug/processors/pry_processor.rb @ line 19 Byebug::PryProcessor.start
step_out 2: /home/sloneorzeszki/lab/pry-byebug/lib/pry-byebug/pry_ext.rb @ line 14 Pry.start_with_pry_byebug
step_out 3: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-0.12.2/lib/pry/core_extensions.rb @ line 47 Object#pry:
step_out 4: place where I put binding.pry  (target location)

but with binding.remote_pry it is:

step_out 1: /home/sloneorzeszki/lab/pry-byebug/lib/byebug/processors/pry_processor.rb @ line 19 Byebug::PryProcessor.start
step_out 2: /home/sloneorzeszki/lab/pry-byebug/lib/pry-byebug/pry_ext.rb @ line 14 Pry.start_with_pry_byebug
step_out 3: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 211 PryRemote::Server#run:
step_out 4: /home/sloneorzeszki/.rvm/gems/ruby-2.5.3/gems/pry-remote-0.1.8/lib/pry-remote.rb @ line 321 Object#remote_pry
step_out 5: place where I put binding.remote_pry

Note: step_out 4 is the same line reported in the discussion above.

There is one more thing, although it might be just my setup (I guess it may influence the order the gems are loaded). When debugging I wasn't really able to bind into pry_remote_ext.rb file. No matter what I did within it, I didn't see any change in a way the gem worked. To me it seems like this file isn't loaded at all. I tried to load it via cli.rb, which generated an error suggesting that the class PryRemote::Server isn't loaded yet (so it can't be overridden). Again, this might be just my setup.

I don't really know enough about pry or byebug to go further with it. This is the first time I'm contributing on GH so I hope I'm not making any blatant mistakes. Thanks for doing this, @deivid-rodriguez

Thank you so much @sloneorzeszki. I find your comment quite insightful and useful. Congrats for your first contribution!

Changing 4 to 5 also works for me. But I cannot find a clear way to submit a fix. How do you calculate the frames you need to step out? It depends on the pry plugins or hacks you have included in your setup 🤔

Thanks, @atd :) If enough people confirm that changing the number to 5 fixes the problem I guess we can assume that's the way to go. It maybe sounds like a bad idea (since we would have to set a different number for every gem having similar problem), but with pry-remote we already have the pry_remote_ext.rb file where we can place most of the code.

I too have a problem thinking about any good-looking solution but I made a fix that works for me - hopefully someone will be able to make something better of it. It's available on my fork -
https://github.com/sloneorzeszki/pry-byebug/commit/81c258f9cce84acd2329d24383f0f3270fd1203e.

Few remarks:

• I had to replace attr_accessor :current_remote_server with setter/getter methods - I don't fully understand consequences of using attr_accessor in modules but the test suite wouldn't even start without that change
• I used prepend instead of alias_method solution - this may possibly cause problems with backward compatibility
• I added a require statement for pry_remote_ext in cli.rb, as mentioned before - in my environment the file wasn't loaded at all, is this intentional?
• number of steps out is set by default to 4 but the number can be passed as a block (not the prettiest solution, I know)
• I didn't add any tests since that would require some more time which I don't have at the moment (never tested anything like this before)

I didn't make a pull request out of it due to above caveats. I will be happy to make it if needed :)

Thanks for all your investigations! I'll try to find some time to look at this! 👍

Thank you for sharing your branch @sloneorzeszki

I have tested it, but I still get the input inside the wrong terminal (the one with the rails s) and outputs does go to the pry-remote terminal

Regarding your comments, you should be able to enclose the attr_accessor :current_remote_server inside class << self; end so you enable PryByebug.current_remote_server (the other way, the instances of a class that includes PryByebug would have the attr_accesor)

About using prepend, I would say it is ok since byebug only works with ruby 2

Finally, you can pass the step_out options within a new options argument to Byebug::PryProcessor.start

I have tested it, but I still get the input inside the wrong terminal (the one with the rails s) and outputs does go to the pry-remote terminal

It was the first time I used this gem, I honestly didn't realize this was the problem (although I did find it pretty odd 😶), I was focused on the step_out thing only. Thank you for your feedback, will look into it in the coming days :)

@atd I applied your suggestions and pushed to my fork (https://github.com/sloneorzeszki/pry-byebug/commit/33d4ba2536a68221ac8c08797b06af5bec5fcaab). Unfortunately I wasn't able to fix the wrong terminal problem even though I spent a few hours on it. Hopefully someone else will be able to go on with that. Thanks again for help.

Part of the problem stems from pry-byebug alias-method-chaining Pry.start, eating the passed arguments, but not conveying those arguments to the original Pry.start call.

The alias-method-chain (lib/pry-byebug/pry_ext.rb:10):

def start_with_pry_byebug(target = TOPLEVEL_BINDING, options = {})
  Byebug::PryProcessor.start unless ENV['DISABLE_PRY']
#                           ^ options not conveyed here

The call to the original Pry.startlib/byebug/processors/pry_processor.rb:117:

def resume_pry
  run do
    @pry = Pry.start_without_pry_byebug(new_binding)
#                                                  ^ options not conveyed here

@JoshCheek posted a hacky fix in #45 (here) as a proof of concept. But I think the idiomatic thing would be to write a companion class to PryProcessor named PryInterface, similar to byebug's other *Processor/*Interface class pairs. It tracks invocation information.

diff --git a/lib/byebug/interfaces/pry_interface.rb b/lib/byebug/interfaces/pry_interface.rb
new file mode 100644
index 0000000..74e410d
--- /dev/null
+++ b/lib/byebug/interfaces/pry_interface.rb
@@ -0,0 +1,14 @@
+# frozen_string_literal: true
+
+require "byebug/core"
+
+module Byebug
+  class PryInterface < LocalInterface
+    attr_accessor :options
+
+    def initialize(options)
+      super()
+      @options = options
+    end
+  end
+end
diff --git a/lib/byebug/processors/pry_processor.rb b/lib/byebug/processors/pry_processor.rb
index 5f29cfd..eb75bfd 100644
--- a/lib/byebug/processors/pry_processor.rb
+++ b/lib/byebug/processors/pry_processor.rb
@@ -1,6 +1,7 @@
 # frozen_string_literal: true
 
 require "byebug/core"
+require "byebug/interfaces/pry_interface"
 
 module Byebug
   #
@@ -13,10 +14,11 @@ module Byebug
     def_delegators :@pry, :output
     def_delegators Pry::Helpers::Text, :bold
 
-    def self.start
+    def self.start(options = {})
       Byebug.start
       Setting[:autolist] = false
       Context.processor = self
+      Context.interface = PryInterface.new(options)
       Byebug.current_context.step_out(4, true)
     end
 
@@ -114,7 +116,7 @@ module Byebug
         if defined?(@pry) && @pry
           @pry.repl(new_binding)
         else
-          @pry = Pry.start_without_pry_byebug(new_binding)
+          @pry = Pry.start_without_pry_byebug(new_binding, interface.options)
         end
       end
     end
diff --git a/lib/pry-byebug/pry_ext.rb b/lib/pry-byebug/pry_ext.rb
index 03c3400..1882e88 100644
--- a/lib/pry-byebug/pry_ext.rb
+++ b/lib/pry-byebug/pry_ext.rb
@@ -7,7 +7,7 @@ class << Pry
 
   def start_with_pry_byebug(target = TOPLEVEL_BINDING, options = {})
     if target.is_a?(Binding) && PryByebug.file_context?(target)
-      Byebug::PryProcessor.start unless ENV["DISABLE_PRY"]
+      Byebug::PryProcessor.start(options) unless ENV["DISABLE_PRY"]
     else
       # No need for the tracer unless we have a file context to step through
       start_without_pry_byebug(target, options)

Having a decoupled class to maintain upstream Pry state/preferences would be great. For example, if this were in place, PryInterface could be also used to configure binding behavior preferences (byebug vs. vanilla pry), closing #45.

Anybody have traction on this issue? I'm using pry-remote standalone, but would really like to navigate!

I've found a way to make it work and opened an MR here #339.

For anyone who's interested, @meinac's fix has been released as a forked version of this gem: https://rubygems.org/gems/gitlab-pry-byebug/versions/3.9.0

For anyone who's interested, @meinac's fix has been released as a forked version of this gem: https://rubygems.org/gems/gitlab-pry-byebug/versions/3.9.0

Thanks @thiago-gitlab that's awesome. Is this fork receiving updates? I see it's pinned to the 0.13.0 version of Pry, which has moved up to 0.14.0

@kylesnowschwartz, it's not because we were hoping that upstream would be eventually fixed. The MR has been open for a few months without any comments, so that hasn't happened yet.

Our fork is here: https://gitlab.com/gitlab-org/gitlab-pry-byebug/-/tree/release_new_version

If anyone feels like contributing an update, I'm sure @meinac would be happy to review it.