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 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.
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.
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
# start detached (on the background)
# start only rails
# start only 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.
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).