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 
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ā
Do I read this correctly that we should remove pry-remote and foreman gems?
Iād be all for going with foreman-start-dev only, we would need to change Foreman :: Contribute and probably few other places, but I think foreman is not the best tool for development. And unless we are using it somewhere else, lets at least stop promoting it.
No, what I suggest is to create a new script that would replace foreman-start-dev which is not widely used and change Procfile so foreman gem actually uses the script to start individual services. The script would also provide a terminal emulator (probably tmux) session creation for those who would like to use debuggers/REPLs.
So I propose best of both worlds and a single entrypoint (one configuration to worry about).
For the record, there is a better PR based on tmuxinator gem and with less shell code: