Does pry-remote work for you?

Hey, I needed to do a quick debugging session today and I could not get pry-remote running. The moment I connect to the process the client disconnects and the server starts the session on the terminal which is not possible with foreman running.

Then I tried byebug and it worked just fine. The pry-remote project seems abandoned and I wonder if anyone use it. We do have pry and other tools included in the development group.

I use pry-remote in production like setups just fine.

scl enable tfm 'gem install pry-remote'
setenforce 0
pry-remote # once you add the binding.remote_pry and restart the foreman service

I gave up on pry-remote and while ago and I use this workflow with byebug:

I think it does not work due to the fact that when using “foreman” (the other foreman) rails do not run in proper terminal. I haven’t checked in more detail tho, but this nullifies the purpose I need remote debugger - the reason is the “foreman” gem which does not emulate terminal properly.

Yeah, it also worked like charm for me. The remote protocol is indeed built-in the project and maintained.

Therefore I propose to add byebug to the development profile of Foreman. We actually already have it today, it gets in as a dependency of pry-byebug:

I think we sholud add it explicitly so both debugger and REPL are available for debugging sessions.

Byebug is not useful without ability to remotely connect, so I am also proposing to create an initializer that will start byebug server when needed:

pry-remote works fine for me, although every time I use it I have to figure out if the gem is pry-remote, pry_remote, remote-pry or remote_pry and if I start a server with binding.pry_remote or binding.remote_pry.

To be honest I never used byebug

I run Foreman in two terminals - one running rails s and another running foreman s webpack. Then binding.pry in the rails terminal works just fine.

This is what I use in development too, just to have a better control (e.g. restart just one service). Opening two terminals is cheap :slight_smile:

2 Likes

There is the scripts/foreman-dev-start script which literally starts webrick on the background and rails on the foreground (you can do this and pry will work) but I am trying to switch to the “foreman” gem.

Honestly I’d rather swap “foreman” with tmux configuration or something similar that will be debugger/repl friendly. Then we can drop the extra script and have only one configuration.

Out of curiosity, do you run rails via foreman rails or in a regular terminal. I think you’re a heavy tmux user so my guess is proper terminal for both processes.

I have an idea of unifying startup scripts Procfile and script/foreman-start-dev into a single shell script that would be manipulating tmux terminal:

# start new tmux with two windows
./foreman-dev start-attached

# start detached (on the background)
./foreman-dev start

# start only rails
./foreman-dev start-rails

# start only webpack
./foreman-dev start-webpack

# similar commands for restart, stop etc

Then Procfile would only call this script to start rails and webpack separately.

This would mean that happy “foreman” gem users could keep using the “foreman” command while users who like debugging could use the script. The script could even work if no tmux was installed, in that case it could simply start processes via shell job functionality (bg/fg etc) of course with the obvious limitation that you could only attach to a single process (rails).

I like another idea - this could be a nice entry point for new users, something like rails init or rails help. We could provide some meaningful information in the foreman-dev help output and also we could provide some useful commands like foreman-dev install-dependencies.

Proper terminals all the way. In development I usually just use regular (non-remote) pry. I usually use remote-pry just when checking something on a hijacked production-like machines.

Yeah, why not. I know some people prefer screen over tmux. I’d most likely stay with 2 unmuxed full terminals anyway, but whatever helps new devs is good. You may be interested in GitHub - iNecas/tmunix: Manage tmux with power of unix tools I used that for a while for start rails, webpack-dev-server, rails console and one empty terminal. However the less custom tools we introduce the easier it is for new contributors.

That made me thinking if we could rescue the exception when webpack-dev-server does not run and print some nicer information to the dev about how to start it, instead of simply “can’t load manifest”