search

adamcooke / procodile

🐊 Run processes in the background (and foreground) on Mac & Linux from a Procfile (for production and/or development environments)
https://procodile.opnsrc.io
MIT License
615 stars 29 forks source link

[Question] Breakpoints #2

Closed whomwah closed 5 years ago

whomwah commented 8 years ago

procodile looks great @adamcooke, thank you! One thing that has always been an issue with these kind of process managers is handling breakpoints in local development. I guess because the code you're adding the breakpoint to is being managed by another process.

Can you think of a way this could be solved in procodile. The use case is to be able to put something like binding.pry in my code and be able to debug as I would if I was running it manually without it being swallowed.

AlexVPopov commented 8 years ago

@whomwah one solution to this is using pry-remote, though I admit it's annoying and using the normal pry is much more convinient. @adamcooke, great job :green_heart:

whomwah commented 8 years ago

@AlexVPopov yes, I've seen than. Like you say though, it can be a bit flaky and seems more of a band-aid, because you can't do what you'd really want to.

jasdeepsingh commented 8 years ago

Oh yes, that would be a great addition! +1

ahmeij commented 8 years ago

Maybe using tmux windows to run (some) processes in the foreground? https://github.com/tmuxinator/tmuxinator is a ruby project that controls tmux which might be used (if it has a usable api)

IlkhamGaysin commented 8 years ago

it'd be great! :+1:

scifisamurai commented 8 years ago

Having the ability to debug via binding.pry statements is the main reason I typically just run rails server or similar commands directly rather than using something else. I agree that it would be great if procodile played nicely with pry/binding.pry.

IlkhamGaysin commented 7 years ago

@adamcooke Any thoughts regarding this question?